<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">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>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><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>