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@apache.org> 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@redhat.com> 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@redhat.com> 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@apache.org> 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@gmail.com> 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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Lukáš Fryč
Software Engineer
Red Hat Mobile | AeroGear.org, FeedHenry.org