[aerogear-dev] GCM Topics - split into two sender implementations?

Summers Pittman supittma at redhat.com
Wed Aug 12 11:04:12 EDT 2015


On Wed, Aug 12, 2015 at 9:41 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Wed, Aug 12, 2015 at 3:36 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Wed, Aug 12, 2015 at 9:31 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 12, 2015 at 3:22 PM, Lukáš Fryč <lukas at fryc.eu> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> /wrt the GCM Topics support PR
>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/626
>>>>
>>>> me and summersp have discussed how JMS should be used to route messages.
>>>>
>>>>
>>>> Current implementation loads tokens and conditionally sends either
>>>> message with registration IDs or topics.
>>>>
>>>> There are two things yet to be solved:
>>>>
>>>>    -  topics can be used up to 1 million registrations, otherwise you
>>>>    have to fall back to enumerating registration IDs
>>>>    - implementation with one sender (GCMPushNotificationSender) is
>>>>    suboptimal
>>>>       - the utilization of the topics can be increased by prioritizing
>>>>       topic message sending first (covering multiple, potentially thousands
>>>>       registrations)
>>>>       - followed by sending registration IDs out
>>>>
>>>>
>>>> That's why I suggested to split implementation to two JMS queues
>>>> talking to two sender impls (e.g. GCMTopicSender
>>>> and GCMRegistrationIdsSender).
>>>>
>>>>    - first we send out topic based messages (for efficiency)
>>>>    - we collect those topics that fail and resend them for processing
>>>>    as registration IDs (fail over)
>>>>       - registration ids sending can start in parallel, but it can't
>>>>       end until we sent out all topics
>>>>
>>>>
>>> I agree that we need a slip here - but does it (GCM) really work like
>>> that ?
>>> I was more thinking/guess that we have to do the math and keep the
>>> device nr. per topic - wondering now, summers, what actually happens if
>>> device 1.000.001 registers w/ the topic? Does GCM fail the device ?
>>>
>>
>> As far as Google's docs say, the device will register with GCM but the
>> topics will fail to send on the server.
>>
>> Specifically when we send the post to Google we will receive a failure
>> messages TOO_MANY_DEVICES.  See the GCM Sender in the PR for exact details.
>>
>
> ok - thanks, so in case of this error - nothing is delivered? or just the
> first 1M ?
>
That is undocumented, but I would assume nothing is delivered.

>
>
>
>
>>
>>
>>>
>>>> Additionally we get an ability to configure these two message routes
>>>> individually on the JMS level (better utilization, transact-ability, fail
>>>> over).
>>>>
>>>
>>> but generally, I think these are two completely different cases,
>>> therefore we need to different senders
>>>
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> ~ Lukas
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150812/41b3739f/attachment.html 


More information about the aerogear-dev mailing list