<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 9:31 AM, Matthias Wessendorf <span dir="ltr">&lt;<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Aug 12, 2015 at 3:22 PM, Lukáš Fryč <span dir="ltr">&lt;<a href="mailto:lukas@fryc.eu" target="_blank">lukas@fryc.eu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi guys,<div><br></div><div>/wrt the GCM Topics support PR <a href="https://github.com/aerogear/aerogear-unifiedpush-server/pull/626" target="_blank">https://github.com/aerogear/aerogear-unifiedpush-server/pull/626</a></div><div><br></div><div>me and summersp have discussed how JMS should be used to route messages.</div><div><br></div><div><br></div><div>Current implementation loads tokens and conditionally sends either message with registration IDs or topics.</div><div><br></div><div>There are two things yet to be solved:</div><div><ul><li> topics can be used up to 1 million registrations, otherwise you have to fall back to enumerating registration IDs</li><li>implementation with one sender (GCMPushNotificationSender) is suboptimal</li><ul><li>the utilization of the topics can be increased by prioritizing topic message sending first (covering multiple, potentially thousands registrations)</li><li>followed by sending registration IDs out</li></ul></ul><div><br></div>That&#39;s why I suggested to split implementation to two JMS queues talking to two sender impls (e.g. GCMTopicSender and GCMRegistrationIdsSender).<br></div><div><ul><li>first we send out topic based messages (for efficiency)</li><li>we collect those topics that fail and resend them for processing as registration IDs (fail over)</li><ul><li>registration ids sending can start in parallel, but it can&#39;t end until we sent out all topics</li></ul></ul></div></div></blockquote><div><br></div></span><div>I agree that we need a slip here - but does it (GCM) really work like that ? </div><div>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 ?</div></div></div></div></blockquote><div><br></div><div>As far as Google&#39;s docs say, the device will register with GCM but the topics will fail to send on the server.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Additionally we get an ability to configure these two message routes individually on the JMS level (better utilization, transact-ability, fail over).</div></div></div></blockquote><div><br></div></span><div>but generally, I think these are two completely different cases, therefore we need to different senders </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr"><div><br></div><div><br></div><div>What do you think?</div><div><br></div><div><br></div><div>Cheers,</div><div><br></div><div>~ Lukas</div></div>
<br></span>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</font></span></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div></div>