Submitting is fully handled asyn. e.g. it took me 350ms to submit 5k of push messages. 
than client returns;

The messaging sub-system of WildFly/EAP than processes those, in batches (e.g. per push network etc)

So, if one sends 100k messages in one batch, the same would be very likely sent via individual requests.
but here we have 1 request, instead of 100k, which also has lot's of problems in terms of costs/overhead

Mainly the internal message broker is decoupled from the web-workers, hence, once uploaded, the processing on the messaging component.

That said, I also think that our Google Summer of Code project (Kafka/HBase) will greatly contribute to a much faster system, being able to handle crazy loads, which is currently already not really possible

PS: I've added a comment to the server PR,

On Mon, Feb 20, 2017 at 9:02 AM, Jose Miguel Gallas Olmedo <> wrote:
​Looks like a very nice feature. I wonder if it will cause very large HTTP request payloads and how problematic this could be? My browser is sometimes slow when loading some heavy website so sending a huge batch might not be so much productive after all. What do you thing?

Disclaimer: this is not a criticism but a innocent question.


On 19 February 2017 at 18:56, Summers Pittman <> wrote:
Oooo That looks cool, I've starred it to take a closer look.

On Sat, Feb 18, 2017 at 1:58 PM, Matthias Wessendorf <> wrote:
the java client update looks like:

Was not hard, some java8 fu, and just appending, internally, the "batch" part of the URL


On Sat, Feb 18, 2017 at 3:09 PM, Matthias Wessendorf <> wrote:

how do people feel about an batch processing endpoint:

If you have a list of different users (via different alias), and want to send them a personalized message (e.g. "Hello $alias, how are things?"), CURRENTLY you'd have to iterate through that list and send a push request for _each_ alias/message pair. Which results in lot's of overhead, and lot's of http requests;

Now, using this new batch endpoint, allows you do iterate through the list, create the actual message, put it to a collection, and after the iteration, you send one HTTP request, containing the message collection.

This results in ONE http request, which it may contain 100's of different messages, for the given Push-Application, instead of 100's of HTTP requests.

Any thoughts ? 



aerogear-dev mailing list

aerogear-dev mailing list

Jose Miguel Gallas Olmedo
Associate QE at Mobile Team, Red Hat

aerogear-dev mailing list