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:

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@redhat.com> wrote:


On Tue, Jul 28, 2015 at 10:20 AM, Sebastien Blanc <scm.blanc@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev