Quoth IRC : ``` 18<filip_> We're evaluating Aerogear at the moment (to replace a server we had build ourselves on top of https://github.com/notnoop/java-apns for the APNS connectivity, and a forked version of the GCM code on https://github.com/google/gcm (which is basically what Aerogear is also using)). I have one 'feature' that I miss a bit in Aerogear, and I wanted to quickly discuss that if possible. 18<filip_> When you send a message to GCM (as documented at https://developers.google.com/cloud-messaging/http-server-ref#table5), GCM gives a result back (which inside Aerogear is mapped to a MulticastResult object) 18<jbossbot> Title:3 HTTP Connection Server Reference | Cloud Messaging | Google Developers 18<filip_> What we do with it is log the returned message_id's, since we like them for debugging purposes 18<filip_> The Developer Console has the possibility to diagnose GCM message sending using a message id (see https://support.google.com/googleplay/android-developer/answer/2663268?hl=en ) 18<jbossbot> Title:3 View & diagnose Google Cloud Messaging (GCM) statistics - Developer Console Help 18<filip_> I think it would be very useful if the GCM message_id's were logged by Aerogear, so that when we want to debug, or just lookup, the message flow for a certain message, I could find it in Aerogear, and look it up in the GCM developer console 18<filip_> Would it be an option to log some information for the MulticastResult object to have, but basically only use to clean-up inactive tokens...? 18<filip_> See https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/GCMPushNotificationSender.java#L127 31<summersp>30 filip_, Seems like it would make a great JIRA 18<filip_> ok, what does that mean? Would you like me to log a JIRA issue explaining this? 31<summersp>30 filip_, Sorry, got distracted 31<summersp>30 TL;DR; yes. I'm looking at things right now to see if this is "Easy" or "Hard". 31<summersp>30 Because it would suck to nuke the logs with tons of message id's, or pass them around to the dashboards when they aren't needed etc etc 31<summersp>30 Anyway 31<summersp>30 I'll make a Jira at https://jira.jboss.org/browse/AGPUSH 18<jbossbot> Title:3 Agile Board - JBoss Issue Tracker 31<summersp>30 Or you can. 18<filip_> Yes, that's also what I was thinking. The multicastId field alone is not useful, you indeed need the individual message_id's 31<summersp>30 Which could end up being a very large amount of data. ```
|