<div dir="ltr"><div><div><div>Hi Matthias,<br></div>I agree with your idea. I think that device counter for Android is really confusing so lets remove it. And as you described it, pending state doesn&#39;t add much value.<br><br></div>Cheers,<br></div>Oleg<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 24, 2017 at 10:30 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">Hi,<div><br></div><div>we do have a problem w/ our current metrics processing. It&#39;s complicated (lot&#39;s of CDI events and two different JMS messaging approaches...) and also slow (JPQL/JDBC) and it does consume a lot of memory and processing time. This is leading to bugs (incorrect stats) and eventually causes down times, due to heavy processing.</div><div><br></div><div>I&#39;d like to dramatically simplify our metrics processing... to something like:</div><div>Success -&gt; could connect to 3rd party, to deliver tokens</div><div>Failure -&gt; something went wrong when talking to 3rd party service.</div><div><br></div><div><br></div><div><div>Right now we do have metrics on push delivery:</div><div>Pending -&gt; the submission to the 3rd party provider is in flight</div><div>Success -&gt; we were able to connect, and could deliver *something*</div><div>Failure -&gt; something obvious, like invalid certificate (APNs), no connection to 3rd party possible, etc</div><div><br></div><div>Besides that, we also do a count on targeted devices. I think there is not really a huge value. For instance if APNs rejects some tokens, we do not track those, we just show how many tokens our DB did find, not more. We don&#39;t show any of real interest. We could improve this (see below), but I doubt that the current implementation is able to handle this well.<br></div><div><br></div><div>Also, on Android/FCM the numbers are even worse. We do, internally, leverage their topics, so we usually end up sending exactly one push to FCM, regardless of how many Android device-tokens we have in the DB. The counter says 1 (one), because the server did target one topic (not n devices).</div><div><br></div><div>So, for now, I&#39;d like to dramatically simplify the code, and go with the above Success/Failure solution.</div><div><br></div><div>However, I honestly think in the long run, we should get something pluggable, that allows us to process the metrics independently, outside of the UPS code base. I think my previous Kafka mail is addressing this partially: The actual response and details about the push job should be logged to some Kafka system, and an independent process should be able to process those. </div><div><br></div><div>This will give us much more freedom and flexibility. Perhaps also, in the future, we want some different stats, and something like Prometheus /Grafana:</div><div><a href="https://prometheus.io/docs/visualization/grafana/" target="_blank">https://prometheus.io/docs/<wbr>visualization/grafana/</a></div></div><div><br></div><div>A more flexible system, with independent metrics &#39;calculation&#39; processing will help us here.</div><div><br></div><div>Any thoughts?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Matthias</div><div><br></div><div><div><br clear="all"><div><br></div>-- <br><div class="m_-8910927331190696749gmail-m_7852728415273694341gmail_signature"><div dir="ltr"><div>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.word<wbr>press.com/</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><wbr>a</div></div></div>
</div></div></font></span></div>
<br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/aerogear-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>Oleg Matskiv<br></div>Associate Quality Engineer<br></div><div>Red Hat Mobile Application Platform<br></div><a href="mailto:omatskiv@redhat.com" target="_blank">omatskiv@redhat.com</a><br></div></div></div></div>
</div>