[aerogear-dev] verification of JMS workflow

[Lukas Fryc]

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 at 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 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20151118/3bdbd703/attachment-0001.html