You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@activemq.apache.org by GitBox <gi...@apache.org> on 2019/07/09 22:26:30 UTC

[GitHub] [activemq-artemis] PiotrKlimczak commented on issue #2747: ARTEMIS-2420 implementation

PiotrKlimczak commented on issue #2747: ARTEMIS-2420 implementation
URL: https://github.com/apache/activemq-artemis/pull/2747#issuecomment-509832927
 
 
   Thanks for your comment @jbertram.
    
   As said, I just really started with Artemis and I was hoping with a few hours of coding, I can add missing features avoiding changes in our software/processes which is JMS centric indeed.
   
   I don't understand why:
   ''the prefixed dead-letter addresses will still need to be manually created which kind of defeats the purpose of this feature which is to automate this process for auto-created addresses and queues.''
   I was trying to find out all usages of dead letter address config and I haven't seen it being used for any address/queue creation anywhere unless I missed it. Or should we create explicitly each address for DLAs/DLQs manually- which I haven't seen in docs, but again I might have missed it?
   
   Regarding the existing solution in Artemis, my problem is that we process lots of messages across many queues and there are occasions where we are getting lots of errors.
   Therefore having everything in a huge bag DLA/DLQ is not the most convenient way to support failures, where customers are obviously in rush and they have different priorities for different processes.
   Also we have integrations, where queue names are dynamic and differs env to env, in which case having fixed config is not possible, while due to our internal standards we must deploy same artifacts to each customer environment.
   I like the ActiveMQ's dynamic nature and it supports us very well, in fact, 95% of our queues are dynamically created because they don't need any customisations to default config- which itself is customised quite a lot.
   Indeed technically we could use filters, however again this is not the most convenient way and for me, this doesn't sound like a solution, but rather as a workaround, which I can imagine would be acceptable in short term but not as a permanent solution - I doubt our support department would agree for that.
   
   Personally, I am happy to invest more of my time to get the solution that would satisfy everybody.
   But it looks like it might require a bit more guidance from your end.
   
   Is there any chance you could provide more details on what is needed (like which class to focus at, what would be your acceptance criteria etc.) so we could both get it done?
   I've seen people asking on some forums/blogs for this feature, so I can't be the only one on this planet who would possibly benefit from this feature :).
   
   WDYT?
   
   Thanks again for your time,
   
   Piotr

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services