awesome, great to hear - For the 1.1.x (mainly 1.1.1 first ;-)) let's see if we can provide an optimized strategy. Lukas was already hinting this on IRC. Tomas, thanks for the updates and the testing effort! On Thu, Nov 5, 2015 at 8:57 AM, Tomáš Hradec <thradec(a)gmail.com&gt; wrote: > Hi all > > I did some testing of JMS workflow used in UPS during sending > notifications. I can confirm, that suggested blocking strategy, as > protection against OOM errors, works as expected. However in worst scenario > could cause blocking 6 of 20 threads (from MDBs pool). So I would suggest > using different approach, with more optimal resource usage, some options > were discussed already with Lukas. > > Regards > Tomas > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I've discussed this further with Tomas and he told me he successfully tested that our impl does not exceed given (configured) memory limits. You have to switch the queue settings to: address-full-policy=BLOCK (default is PAGE, which can cause exceeding the disk space and perhaps slow down the node if there are really lot of recipients. which is, well, not ideal) :-). The best option would be to use address-full-policy=FAIL. I believe this will fail transaction and the queue will try to redeliver, but still have to get to confirming that. (This can be configured to exponential back-off and try to deliver so many times that it really does its job (such as try to redeliver after 5 seconds, but repeat that e.g. up to 2 hours, then fail the message finally as non-deliverable)). On Thu, Nov 5, 2015 at 10:43 AM, Lukas Fryc <lfryc(a)redhat.com&gt; wrote: > I've updated the related issue to track the idea: > https://issues.jboss.org/browse/AGPUSH-1521 > > On Thu, Nov 5, 2015 at 9:22 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > >> awesome, great to hear - >> >> For the 1.1.x (mainly 1.1.1 first ;-)) let's see if we can provide an >> optimized strategy. Lukas was already hinting this on IRC. >> >> Tomas, thanks for the updates and the testing effort! >> >> On Thu, Nov 5, 2015 at 8:57 AM, Tomáš Hradec <thradec(a)gmail.com&gt; wrote: >> >>> Hi all >>> >>> I did some testing of JMS workflow used in UPS during sending >>> notifications. I can confirm, that suggested blocking strategy, as >>> protection against OOM errors, works as expected. However in worst scenario >>> could cause blocking 6 of 20 threads (from MDBs pool). So I would suggest >>> using different approach, with more optimal resource usage, some options >>> were discussed already with Lukas. >>> >>> Regards >>> Tomas >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Lukáš Fryč > Software Engineer > Red Hat Mobile | AeroGear.org, FeedHenry.org > -- Lukáš Fryč Software Engineer Red Hat Mobile | AeroGear.org, FeedHenry.org _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

There is an issue covering that: https://issues.jboss.org/browse/AGPUSH-1420 Should we schedule it for 1.1.1? On Mon, Nov 16, 2015 at 9:40 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Lukas, Tomas, > > good input, on the different settings - can you of you send a PR against > our aerogear.org repo, so that we have this documented in our user guide > for configuration? > > On Mon, Nov 16, 2015 at 8:51 PM, Lukas Fryc <lfryc(a)redhat.com&gt; wrote: > >> I've discussed this further with Tomas and he told me he successfully >> tested that our impl does not exceed given (configured) memory limits. >> >> You have to switch the queue settings to: address-full-policy=BLOCK >> (default is PAGE, which can cause exceeding the disk space and perhaps slow >> down the node if there are really lot of recipients. which is, well, not >> ideal) :-). >> The best option would be to use address-full-policy=FAIL. I believe this >> will fail transaction and the queue will try to redeliver, but still have >> to get to confirming that. (This can be configured to exponential back-off >> and try to deliver so many times that it really does its job (such as try >> to redeliver after 5 seconds, but repeat that e.g. up to 2 hours, then fail >> the message finally as non-deliverable)). >> >> On Thu, Nov 5, 2015 at 10:43 AM, Lukas Fryc <lfryc(a)redhat.com&gt; wrote: >> >>> I've updated the related issue to track the idea: >>> https://issues.jboss.org/browse/AGPUSH-1521 >>> >>> On Thu, Nov 5, 2015 at 9:22 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>>> awesome, great to hear - >>>> >>>> For the 1.1.x (mainly 1.1.1 first ;-)) let's see if we can provide an >>>> optimized strategy. Lukas was already hinting this on IRC. >>>> >>>> Tomas, thanks for the updates and the testing effort! >>>> >>>> On Thu, Nov 5, 2015 at 8:57 AM, Tomáš Hradec <thradec(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Hi all >>>>> >>>>> I did some testing of JMS workflow used in UPS during sending >>>>> notifications. I can confirm, that suggested blocking strategy, as >>>>> protection against OOM errors, works as expected. However in worst scenario >>>>> could cause blocking 6 of 20 threads (from MDBs pool). So I would suggest >>>>> using different approach, with more optimal resource usage, some options >>>>> were discussed already with Lukas. >>>>> >>>>> Regards >>>>> Tomas >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Lukáš Fryč >>> Software Engineer >>> Red Hat Mobile | AeroGear.org, FeedHenry.org >>> >> >> >> >> -- >> Lukáš Fryč >> Software Engineer >> Red Hat Mobile | AeroGear.org, FeedHenry.org >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Lukáš Fryč Software Engineer Red Hat Mobile | AeroGear.org, FeedHenry.org _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev