[aerogear-dev] GCM Topics - split into two sender implementations?
Lukáš Fryč
lukas.fryc at gmail.com
Thu Aug 13 07:42:53 EDT 2015
On Wed, Aug 12, 2015 at 3:31 PM, 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
>
Yes, that's certainly possible in a case we are able to find registration
IDs for all devices subscribed to a given topic.
Actually our current strategy for detecting end of sending session is based
on token (device) counting.
> - wondering now, summers, what actually happens if device 1.000.001
> registers w/ the topic? Does GCM fail the device ?
>
>
>> 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/20150813/ffed16f8/attachment.html
More information about the aerogear-dev
mailing list