Submitting is fully handled asyn. e.g. it took me 350ms to submit 5k of
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 <
Looks like a very nice feature. I wonder if it will cause very large
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 <supittma(a)redhat.com> 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 <matzew(a)apache.org>
>> the java client update looks like:
>> Was not hard, some java8 fu, and just appending, internally, the
>> part of the URL
>> On Sat, Feb 18, 2017 at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org>
>>> 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
>>> CURRENTLY you'd have to iterate through that list and send a push
>>> 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 ?
>>> Matthias Wessendorf
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>> Matthias Wessendorf
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>> aerogear-dev mailing list
> aerogear-dev mailing list
*Jose Miguel Gallas Olmedo*
Associate QE at Mobile Team, *Red Hat*
+34 618 488 633 <+34%20618%2048%2086%2033>
aerogear-dev mailing list