[aerogear-dev] UPS using JMS update

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] UPS using JMS update

Lukas Fryc
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Sebastien Blanc
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Matthias Wessendorf
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?

On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;lukas.fryc@gmail.com&#39;);" target="_blank">lukas.fryc@...> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Sebastien Blanc


On Fri, Apr 3, 2015 at 1:50 PM, Matthias Wessendorf <[hidden email]> wrote:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?
+1, I was exactly thinking the same, since we are tied to wf/eap, subsystem makes a lot of sense IMO
 


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Jay Balunas
This all sounds really good to me!  The priority would be wf/eap imo, with others if very easy, or if community members want to jump in and add their favorite.

On Fri, Apr 3, 2015 at 7:54 AM, Sebastien Blanc <[hidden email]> wrote:


On Fri, Apr 3, 2015 at 1:50 PM, Matthias Wessendorf <[hidden email]> wrote:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?
+1, I was exactly thinking the same, since we are tied to wf/eap, subsystem makes a lot of sense IMO
 


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Lukas Fryc
In reply to this post by Matthias Wessendorf
Do I read well that the subsystem would be the ONLY distribution mechanism?

Created https://issues.jboss.org/browse/AGPUSH-1354 btw. Feel free to comment there.

~ Lukas

pá 3. 4. 2015 v 13:50 odesílatel Matthias Wessendorf <[hidden email]> napsal:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Matthias Wessendorf
Not sure, I think that was my question though

On Tue, Apr 7, 2015 at 9:08 AM, Lukáš Fryč <[hidden email]> wrote:
Do I read well that the subsystem would be the ONLY distribution mechanism?

Created https://issues.jboss.org/browse/AGPUSH-1354 btw. Feel free to comment there.

~ Lukas

pá 3. 4. 2015 v 13:50 odesílatel Matthias Wessendorf <[hidden email]> napsal:

Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] UPS as WildFly Subsystem (was: UPS using JMS)

Lukas Fryc
I reached out to Stian in order to fully understand the "Why" behind Keycloak offering a subsystem, and he identified two benefits:

* smaller appliance downloads
* easier to patch modules than monolithic WAR

Can you see anything else?

The question is how much relevant are these benefits for us, since we depend much more on Java EE (especially with JMS coming).



In case of UPS, we can definitely strip some download Megabytes for (potential) appliance distribution (good for microservices oriented architectures),

while still providing installation of subsystem to existing Wildfly EE instances. We can continue shipping WAR just for sake of backwards compatibility in case it will appear to be effortless.



However I agree that UPS as WF subsystem is a direction worth to explore!

~ Lukas





út 7. 4. 2015 v 9:18 odesílatel Matthias Wessendorf <[hidden email]> napsal:
Not sure, I think that was my question though

On Tue, Apr 7, 2015 at 9:08 AM, Lukáš Fryč <[hidden email]> wrote:
Do I read well that the subsystem would be the ONLY distribution mechanism?

Created https://issues.jboss.org/browse/AGPUSH-1354 btw. Feel free to comment there.

~ Lukas

pá 3. 4. 2015 v 13:50 odesílatel Matthias Wessendorf <[hidden email]> napsal:

Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS as WildFly Subsystem (was: UPS using JMS)

Matthias Wessendorf


On Tue, Apr 7, 2015 at 9:49 AM, Lukáš Fryč <[hidden email]> wrote:
I reached out to Stian in order to fully understand the "Why" behind Keycloak offering a subsystem, and he identified two benefits:

* smaller appliance downloads
* easier to patch modules than monolithic WAR

Can you see anything else?

The question is how much relevant are these benefits for us, since we depend much more on Java EE (especially with JMS coming).


I think it's worth to evaluate once we got JMS working and integrated. I don't think it has to come now - it was more an open question for future development tasks 



In case of UPS, we can definitely strip some download Megabytes for (potential) appliance distribution (good for microservices oriented architectures),

while still providing installation of subsystem to existing Wildfly EE instances. We can continue shipping WAR just for sake of backwards compatibility in case it will appear to be effortless.

Perhaps a 2.0.0 can be subsystem only?
 



However I agree that UPS as WF subsystem is a direction worth to explore!

~ Lukas





út 7. 4. 2015 v 9:18 odesílatel Matthias Wessendorf <[hidden email]> napsal:
Not sure, I think that was my question though

On Tue, Apr 7, 2015 at 9:08 AM, Lukáš Fryč <[hidden email]> wrote:
Do I read well that the subsystem would be the ONLY distribution mechanism?

Created https://issues.jboss.org/browse/AGPUSH-1354 btw. Feel free to comment there.

~ Lukas

pá 3. 4. 2015 v 13:50 odesílatel Matthias Wessendorf <[hidden email]> napsal:

Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Lukas Fryc
In reply to this post by Jay Balunas
Okay, first prototype is reading for testing and review: https://github.com/aerogear/aerogear-unifiedpush-server/pull/522

po 6. 4. 2015 v 20:17 odesílatel Jay Balunas <[hidden email]> napsal:
This all sounds really good to me!  The priority would be wf/eap imo, with others if very easy, or if community members want to jump in and add their favorite.

On Fri, Apr 3, 2015 at 7:54 AM, Sebastien Blanc <[hidden email]> wrote:


On Fri, Apr 3, 2015 at 1:50 PM, Matthias Wessendorf <[hidden email]> wrote:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?
+1, I was exactly thinking the same, since we are tied to wf/eap, subsystem makes a lot of sense IMO
 


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS as WildFly Subsystem (was: UPS using JMS)

Karel Piwko
In reply to this post by Lukas Fryc


On Tue, Apr 7, 2015 at 9:49 AM, Lukáš Fryč <[hidden email]> wrote:
I reached out to Stian in order to fully understand the "Why" behind Keycloak offering a subsystem, and he identified two benefits:

* smaller appliance downloads
* easier to patch modules than monolithic WAR

Can you see anything else?

* Easier configuration. Subsystem can provide both CLI and GUI configuration layer for very small effort.

 

The question is how much relevant are these benefits for us, since we depend much more on Java EE (especially with JMS coming).



In case of UPS, we can definitely strip some download Megabytes for (potential) appliance distribution (good for microservices oriented architectures),

while still providing installation of subsystem to existing Wildfly EE instances. We can continue shipping WAR just for sake of backwards compatibility in case it will appear to be effortless.



However I agree that UPS as WF subsystem is a direction worth to explore!

~ Lukas





út 7. 4. 2015 v 9:18 odesílatel Matthias Wessendorf <[hidden email]> napsal:
Not sure, I think that was my question though

On Tue, Apr 7, 2015 at 9:08 AM, Lukáš Fryč <[hidden email]> wrote:
Do I read well that the subsystem would be the ONLY distribution mechanism?

Created https://issues.jboss.org/browse/AGPUSH-1354 btw. Feel free to comment there.

~ Lukas

pá 3. 4. 2015 v 13:50 odesílatel Matthias Wessendorf <[hidden email]> napsal:

Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Lukas Fryc
In reply to this post by Lukas Fryc
Hi guys,

as first major UPS release (1.1.0) with JMS-based token batching will be landing soon,

just wanted to document how it can be configured for optimal throughput and failover, just in case someone wants to play with that right now:




Cheers,

~ Lukas

On Wed, Apr 8, 2015 at 5:57 PM, Lukáš Fryč <[hidden email]> wrote:
Okay, first prototype is reading for testing and review: https://github.com/aerogear/aerogear-unifiedpush-server/pull/522

po 6. 4. 2015 v 20:17 odesílatel Jay Balunas <[hidden email]> napsal:

This all sounds really good to me!  The priority would be wf/eap imo, with others if very easy, or if community members want to jump in and add their favorite.

On Fri, Apr 3, 2015 at 7:54 AM, Sebastien Blanc <[hidden email]> wrote:


On Fri, Apr 3, 2015 at 1:50 PM, Matthias Wessendorf <[hidden email]> wrote:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?
+1, I was exactly thinking the same, since we are tied to wf/eap, subsystem makes a lot of sense IMO
 


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Matthias Wessendorf
awesome!

On Friday, 23 October 2015, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

as first major UPS release (1.1.0) with JMS-based token batching will be landing soon,

just wanted to document how it can be configured for optimal throughput and failover, just in case someone wants to play with that right now:




Cheers,

~ Lukas

On Wed, Apr 8, 2015 at 5:57 PM, Lukáš Fryč <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;lukas.fryc@gmail.com&#39;);" target="_blank">lukas.fryc@...> wrote:
Okay, first prototype is reading for testing and review: https://github.com/aerogear/aerogear-unifiedpush-server/pull/522

po 6. 4. 2015 v 20:17 odesílatel Jay Balunas <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;jbalunas@redhat.com&#39;);" target="_blank">jbalunas@...> napsal:

This all sounds really good to me!  The priority would be wf/eap imo, with others if very easy, or if community members want to jump in and add their favorite.

On Fri, Apr 3, 2015 at 7:54 AM, Sebastien Blanc <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;scm.blanc@gmail.com&#39;);" target="_blank">scm.blanc@...> wrote:


On Fri, Apr 3, 2015 at 1:50 PM, Matthias Wessendorf <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;matzew@apache.org&#39;);" target="_blank">matzew@...> wrote:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?
+1, I was exactly thinking the same, since we are tied to wf/eap, subsystem makes a lot of sense IMO
 


On Friday, April 3, 2015, Sebastien Blanc <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;scm.blanc@gmail.com&#39;);" target="_blank">scm.blanc@...> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UPS using JMS update

Matthias Wessendorf
I think this would be a nice addition to the guide, on our homepage as well 

On Fri, Oct 23, 2015 at 12:30 PM, Matthias Wessendorf <[hidden email]> wrote:
awesome!


On Friday, 23 October 2015, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

as first major UPS release (1.1.0) with JMS-based token batching will be landing soon,

just wanted to document how it can be configured for optimal throughput and failover, just in case someone wants to play with that right now:




Cheers,

~ Lukas

On Wed, Apr 8, 2015 at 5:57 PM, Lukáš Fryč <[hidden email]> wrote:
Okay, first prototype is reading for testing and review: https://github.com/aerogear/aerogear-unifiedpush-server/pull/522

po 6. 4. 2015 v 20:17 odesílatel Jay Balunas <[hidden email]> napsal:

This all sounds really good to me!  The priority would be wf/eap imo, with others if very easy, or if community members want to jump in and add their favorite.

On Fri, Apr 3, 2015 at 7:54 AM, Sebastien Blanc <[hidden email]> wrote:


On Fri, Apr 3, 2015 at 1:50 PM, Matthias Wessendorf <[hidden email]> wrote:
Cool stuff

I am totally fine having this tied ti wf/eap

wondering: at some point, should we offer a dist as (only) subststem for wf/eap?
+1, I was exactly thinking the same, since we are tied to wf/eap, subsystem makes a lot of sense IMO
 


On Friday, April 3, 2015, Sebastien Blanc <[hidden email]> wrote:
That all sounds very good :) 
Thanks for the headupate, I will soon give it a try.

On Fri, Apr 3, 2015 at 10:34 AM, Lukáš Fryč <[hidden email]> wrote:
Hi guys,

so as outlined in previous thread [1], I have prototyped a JMS batching approach for push message delivery.




We've discussed the approach with Matthias, Mirek Novak and Ondrej Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents describes a concept that we have came with:








Implementation-wise, I've so far prototyped the messaging part (split SenderService functionality to two subsequent queues with MDBs as shown on diagram),

but that's just a start, since we must configure it appropriately for efficiency (queue configuration and batch sizes) and verify that configuration works as expected,

the prototype lives on a branch (unpolished, to be squashed later): https://github.com/lfryc/aerogear-unifiedpush-server/tree/jms-batching

Off course, you can play with it already. :-)





Apart from the new requirement of using Java EE full profile (JMS), the prototype leverages implementation-specific configurations and APIs:
  • org.hibernate.Query for token streaming / batch fetching
  • HornetQ configurations of queue size, blocking behavior and message de-duplication
That pretty much binds us to WildFly/EAP - we can tweak it to run on any compliant app server, but without specific configurations it won't work properly.



Once configured and functionally tested (that can even wait for Beta2 I guess),

we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite contains mocks of APNS/GCM against which we can load test.



Cheers!

~ Lukas



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev