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

Summers Pittman supittma at redhat.com
Wed Aug 12 09:36:45 EDT 2015


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.


>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150812/df3b239b/attachment.html 


More information about the aerogear-dev mailing list