[aerogear-dev] GCM Topics in UPS

[Lukáš Fryč]

Continuing on this discussion,

I remember we have met with Summers around this idea to identify what we
can expect from GCM Topics when considering how UPS works internally with
message queues.

The ideal implementation as Summers suggested is to try pushing via a GCM
Topic and if push can't be performed this way, fall back to device-token
based push.


In terms of UPS/JMS, I believe we should split GCM traffic into two queues:


   - GCMTokenBatchQueue
   - GCMTopicQueue

You can use this diagram to get better idea:
https://docs.google.com/drawings/d/13IsJWPSJNYXtst-UVxQYmzH36C_EXQMYYr_jcu7nFmE/edit


Then the algorithm can be drawn as:

1. TokenLoader will identify categories/topics it can use to optimize GCM
message dispatching - it will push appropriate GCMTopicQueue events and
potentially send also GCMTokenBatchQueue events for devices that are not
covered by GCM topics

2. TokenLoader should also perform DB count for each category/topic, and if
it should go beyond 1 million tokens limit, it falls back to use device
tokens

3. if for any reason the push to GCM topic fails we can still expand device
tokens - in that case the only implementation detail is that we don't know
whether device tokens are all loaded until all topic-based messages are
processed


On Tue, Jul 28, 2015 at 4:40 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Tue, Jul 28, 2015 at 10:20 AM, Sebastien Blanc <scm.blanc at gmail.com>
> wrote:
>
>> Yo !
>> I have not enough info on the GCM Topic stuff but reading your message it
>> sounds that we should leverage this "transparently" for the user , meaning
>> it just uses the UPS categories and under the hood we use the GCM topics
>> stuff.
>> Like you said we have to handle the fall over if they are more than 1
>> million user but since we use JMS batches with counting that should not be
>> too hard (but Lukas should be able to give us more info on that)
>>
> Awesome.  I'll run ahead with my ideas then and let people hash out their
> merits in the PR.
>
>>
>>
>> On Mon, Jul 27, 2015 at 5:22 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>> So I've got a few ideas for how to implement this, but I hope some
>>> people more experienced with the platform can give some feedback before.
>>>
>>> Quick Background:
>>> In UPS right now we have a concept of categories.  A single UPS message
>>> can be broadcast to a bunch of devices which are subscribed to this
>>> category.  Google now supports this for GCM on Chrome, iOS, and Android so
>>> UPS can send a single message to GCM and GCM will broadcast that to up to a
>>> million devices.
>>> End Quick Background
>>>
>>> So first, how do we switch between sending a message to each device in a
>>> category to sending a topic message to GCM?
>>>
>>> In TokenLoader.java#L113 we are using the clientInstallationService to
>>> build a string of deviceTokens based on the variant and message criteria.
>>> Is there any reason we can't create a "topicToken" which will be recognized
>>> later by GCMPushNotificationSender?  Another benefit to making this change
>>> here is that if we have over a million subscribers to the category we can
>>> just default to the default messaging.
>>>
>>> There is also an open issue of whether or not we will update the clients
>>> to filter based on what category a message was sent to.  To do this we will
>>> have to include the category information in the message when we send it to
>>> devices going forward.  In GCM a topic message includes this information.
>>> This means that if we have over a million subscriptions in the topic we
>>> will need to fall back to using the category information anyway.
>>>
>>> Continuing on from the thread of falling back, it is possible for a
>>> topic message to fail to send because there are too many subscribers.  How
>>> would UPS handle regenerating the messages as deviceToken instead of
>>> topicToken messages?
>>>
>>> Of course if someone has a better idea than "topicTokens" I'm all ears.
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> 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/20160315/fd3ba256/attachment.html