[aerogear-dev] verification of JMS workflow

[Matthias Wessendorf]

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20151116/270a2015/attachment.html