Also to add, the filtering criteria for the DLC queue should change. Currently the queues are checked as to whether, it 'contains' the string "DeadLetterChannel". Whereas it makes it possible for a queue which has a names such as ex :- "abcDeadLetterChannel" to be diverted to the DLC queue.
This should be changed to identify for a proper DLC signature and then divert the messages to the DLC queue accordingly. The server side implementation which distinguishes the DLC queues could be found from the function isDeadLetterQueue() located in the DLCQueueUtils class. Thanks, Pamod On Mon, Mar 24, 2014 at 3:31 PM, Ishara Premadasa <[email protected]> wrote: > We (Pamod,Hasitha,Shammi and myself ) had a meeting on the current state > of the DLC implementation. Following is the concerns raised and the agreed > solutions. > > *1. What if user deletes original queue when there are messages addressed > to that queue remains in DLC ?* > > When user decides to delete queue since that means he is no longer > interested in that queue of messages came under that. Therefore when user > deletes queue we delete the DLC messages which are address to the original > queue. > > *2. Users should not be able to publish, subscribe to DLC but only to > browse queue. ?* > > Currently this is done by comparing queue name against DLC queue nameand > restricting access if that matches. Indika is currently working on > implementing queue permission model for MB, and once this is complete we > can simply enable on 'Browse' option for DLC and disable other permissions. > Created [1] for this. > > @Indika, > > Pls note we need to provide a specific 'browse' permission option in queue > security model too. > > *3. What would be the expiration time for messages in DLC?* > > They will be in the queue for lifetime. Messages won't be removed from DLC > if not deleted/restored by the user. > > @Pamod/Hasitha, > pls add if i missed anything. > > Thanks! > Ishara > > [1] https://wso2.org/jira/browse/MB-486 > > > On Mon, Mar 24, 2014 at 3:11 PM, Ishara Premadasa <[email protected]> wrote: > >> Hi Asanka/Shani, >> >> >> On Mon, Mar 24, 2014 at 12:11 PM, Shani Ranasinghe <[email protected]>wrote: >> >>> Hi, >>> >>> +1, yes we could use the same way the queue's are handled. Have the list >>> of queues in DLC with the destination queue name, and number of messages, >>> and through the browse button you can browse the message. >>> >> >> yes, we can do this categorization as a future improvement. >> >>> >>> >>> On Sun, Mar 23, 2014 at 11:36 PM, Pamod Sylvester <[email protected]>wrote: >>> >>>> +1 for the approach to add further filtering per queue. Currently from >>>> the server the destination queue information is sent to the UI. We might >>>> need to add some filtering per queue basis and re categorize them. >>>> >>>> @Ishara/Shani : WDYT about the approach ? >>>> >>>> >>>> On Mon, Mar 24, 2014 at 11:55 AM, Asanka Vithanage <[email protected]>wrote: >>>> >>>>> Hi All, >>>>> >>>>> While going through the current DLC implementation, I felt there is a >>>>> room to improve the UI side of the DLC further. >>>>> >>>>> Currently we are storing all the dead letters in an single queue, and >>>>> only the interface [1] available to access DLC queue. >>>>> There can be thousand no of messages from different queues stored on >>>>> DLC queue So it wont be easy to sort out messages belong to a single queue >>>>> and do a required operation like restore, purge with the current >>>>> implementation. >>>>> >>>>> As a solution while keeping the dead letter channel UI, we can filter >>>>> out all the dead letters according to the queues and keep a link on the >>>>> available queue details UI [2] with the dead letter message count. So >>>>> users >>>>> can get a full view of queue status in an one place and do the all queue >>>>> related operations. >>>>> >>>> >> +1, As i have stated above, we will enable per queue viewing of message >> count and browse the content in future so users will find it easy monitor >> the DLC. If so there won't be no need to get the DLC message count from >> original queue. >> >> Thanks! >> >>> >>>>> WDYT? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Mar 22, 2014 at 2:42 PM, Pamod Sylvester <[email protected]>wrote: >>>>> >>>>>> The latest code of the DLC implementation is committed with r198710. >>>>>> Currently we're progressing in implementing the feature to be tenant >>>>>> aware, >>>>>> >>>>>> for the tenant aware model a DLC queue will be created per tenant, >>>>>> the queue signature will be *{tenantdomain}/DeadLetterChannel*. >>>>>> >>>>>> The above model should be adopted in the UI as well, where the DLC >>>>>> queue should be filtered and pointed based on the above signature. >>>>>> >>>>>> @Shani/Ishara : will it be possible to reflect the changes in the UI >>>>>> as well ? >>>>>> >>>>>> >>>>>> On Fri, Feb 28, 2014 at 2:39 PM, Pamod Sylvester <[email protected]>wrote: >>>>>> >>>>>>> Attached diff contains the Dead Letter Channel (DLC) server >>>>>>> side implementation. Shani will be able to provide input on the UI >>>>>>> component. >>>>>>> >>>>>>> The following is the nature of the DLC feature implementation, >>>>>>> >>>>>>> ~ External parties will not be allowed to publish/subscribe to the >>>>>>> DLC queue. >>>>>>> ~ Messages in the DLC could be restored back to its origin queue or >>>>>>> could be deleted (When deleting it was ensured that data from the >>>>>>> NodeQueue >>>>>>> CF, GlobalQueueCF and MessageContentCF was deleted) >>>>>>> >>>>>>> In addition to the above, an enhancement was Incorporated which will >>>>>>> allow a user to specify a different destination queue other than its >>>>>>> origin >>>>>>> queue for the message to be restored. The admin service signature for >>>>>>> the functionality is as follows, >>>>>>> >>>>>>> restoreMessagesFromDeadLetterQueueToDifferentDestination(String[] >>>>>>> messageIDs, String destination) >>>>>>> >>>>>>> @Shani : will it be possible for you to add the capability in the UI >>>>>>> to allow users to specify a destination queue of their choice and invoke >>>>>>> the above service ? >>>>>>> >>>>>>> Please do let know if there're any amendments to be done in the >>>>>>> existing flows. >>>>>>> >>>>>>> Thanks, >>>>>>> Pamod >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Feb 15, 2014 at 11:14 AM, Pamod Sylvester <[email protected]>wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> The current status of the DLC implementation is described from the >>>>>>>> following, >>>>>>>> >>>>>>>> ~ During the time where the messages are intended to be dropped >>>>>>>> after the re-trying count has exceeded, it will first be stored in the >>>>>>>> Dead >>>>>>>> Letter Channel queue which is an entry of the NodeQueues CF and the >>>>>>>> messages will be purged. >>>>>>>> ~ Implemented the functionality to delete a specific message from >>>>>>>> the DLC through providing it an id of the message, and also restore a >>>>>>>> message back >>>>>>>> ~ The re storing process will basically cut-past the message >>>>>>>> content stored in the DLC entry in the NodeQueues CF back to the Global >>>>>>>> Queue. >>>>>>>> >>>>>>>> TO-DOs >>>>>>>> >>>>>>>> ~ Currently the dead-letter queue is created and listed as a >>>>>>>> general queue, which will also be listed along with the other queues. >>>>>>>> Need >>>>>>>> to discuss and figure out to list it as a separate entity. Need to >>>>>>>> modify >>>>>>>> the permissions of that queue which will prevent the external users >>>>>>>> from >>>>>>>> subscribing/publishing to this queue >>>>>>>> ~Need to integrate with the UI and test the use cases in real time >>>>>>>> >>>>>>>> I've also attached the diff of the current implementation. Please >>>>>>>> do let know of the amendments/modification which should be made. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Pamod >>>>>>>> >>>>>>>> -- >>>>>>>> *Pamod Sylvester * >>>>>>>> * Software Engineer * >>>>>>>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>>>>>>> email: [email protected] cell: +94 77 7779495 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Pamod Sylvester * >>>>>>> * Software Engineer * >>>>>>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>>>>>> email: [email protected] cell: +94 77 7779495 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Pamod Sylvester * >>>>>> * Software Engineer * >>>>>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>>>>> email: [email protected] cell: +94 77 7779495 >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Asanka Vithanage >>>>> Senior Software Engineer -QA >>>>> Mobile: +94 0716286708 >>>>> Email: [email protected] >>>>> WSO2 Inc. www.wso2.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Pamod Sylvester * >>>> * Software Engineer * >>>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 7779495 >>>> >>> >>> >>> >>> -- >>> Thanks and Regards >>> *, Shani Ranasinghe* >>> Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 77 2273555 >>> linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab >>> >> >> >> >> -- >> Ishara Premasada >> Software Engineer, >> WSO2 Inc. http://wso2.com/ >> >> >> *Blog : http://isharapremadasa.blogspot.com/ >> <http://isharapremadasa.blogspot.com/>Twitter : >> https://twitter.com/ishadil <https://twitter.com/ishadil> Mobile : >> +94 714445832 <%2B94%20714445832>* >> >> >> > > > -- > Ishara Premasada > Software Engineer, > WSO2 Inc. http://wso2.com/ > > > *Blog : http://isharapremadasa.blogspot.com/ > <http://isharapremadasa.blogspot.com/>Twitter : > https://twitter.com/ishadil <https://twitter.com/ishadil> Mobile : > +94 714445832 <%2B94%20714445832>* > > > -- *Pamod Sylvester * * Software Engineer * Integration Technologies Team, WSO2 Inc.; http://wso2.com email: [email protected] cell: +94 77 7779495
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
