[aerogear-dev] Help needed on AGPUSH-848
Matthias Wessendorf
matzew at apache.org
Thu Jul 31 09:54:18 EDT 2014
On Thu, Jul 31, 2014 at 3:44 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:
>
>
>
> On Thu, Jul 31, 2014 at 3:17 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>>
>> On Thu, Jul 31, 2014 at 2:52 PM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf <
>>>>> matzew at apache.org> wrote:
>>>>>
>>>>>> I think original idea was to show the three most busy (in number of
>>>>>> receives, not installations)
>>>>>>
>>>>> The total number or receives for one Variant , right ?
>>>>> So, if variant A "sended" a first time to 20 receivers and after that
>>>>> did a selective send 5 : the number that must showned is 25
>>>>> And we want the top 3 of this total ?
>>>>>
>>>>
>>>> uhm, there was a thread in the past. Burr added something, and
>>>> Hylke.... and we were somewhat talked into this (I guess we did not think
>>>> too much about it :-( )
>>>>
>>>> So... I think.....
>>>>
>>>> we perhaps could:
>>>> * show the most (three) recent variants (and their # of receivers)
>>>>
>>> We could do that but then we will need to change the naming
>>>
>>
>> I don't mind renaming !
>>
>>
>>
>>
>>
>>>
>>>> But IMO not doing a count. Perhaps that means some code needs to be
>>>> rewritten...
>>>>
>>>
>>> Well, I just managed to modify the query to really get the 3 variants
>>> having send to the most receivers :
>>>
>>> createQuery("select distinct vmi.variantID, SUM(vmi.receivers),
>>> vmi.pushApplicationID from VariantMetricInformation vmi" +
>>> " where vmi.variantID IN (select t.variantID from
>>> Variant t where t.developer = :developer)" +
>>> " GROUP BY vmi.variantID ORDER BY SUM(vmi.receivers) " +
>>> DESC)
>>> .setMaxResults(3)
>>> .setParameter("developer", loginName)
>>> .getResultList();
>>>
>>> And the code don't need to be rewitten (just changing the label on the
>>> dashboard that is now a bit confusing)
>>>
>>
>> ah, cool; Yeah - I've zero concerns in chaning the label :-)
>>
>>
>>
>>>
>>>>
>>>> Also... "Most active" could mean something else:
>>>> * TOTAL number of receivers (per variant/app) -> like a count
>>>>
>>> Yeah that is what my query above does now
>>>
>>
>> Ok. So you don't like the "show the most (three) recent variants (and
>> their # of receivers) " ? :-)
>>
> Yeah why not :) , we just have to choose something that will be a real
> useful information, I would like from the rest of the team.
>
yes, I'd be interested in hearing from others as well
> Then, if we go for this I need some clarification :
> - most recent variants, you mean most recent "active" variant, meaning the
> most recent that sent out a Push Message ?
>
yep
> Because if you meant on Variant creation date, we don't have this info :)
> - Number of receivers, sorry to ask again, I know you make the distinction
> with installations, but you mean the number of active tokens (i.e : we have
> 20 "active" (not toggled off) tokens, or the total of receivers for all
> the sent messages (i.e : Message A was sent to 10 receivers, Message B was
> sent to 5 receivers, we show 15 ) ?
>
I'd expect a 5 here (or a 15) :) - not sure
-M
>
>
>>
>>
>>
>>
>>> * TOTAL number of messages (per vairant/app) -> like a count on the
>>>> actual message
>>>>
>>>>
>>>>
>>>> I think I do (now) like the first (show the most (three) recent
>>>> variants (and their # of receivers) ) the best :-)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc <
>>>>>> scm.blanc at gmail.com> wrote:
>>>>>>
>>>>>>> BTW,
>>>>>>> I wonder how we had in mind the computing of the 3 busiest variants,
>>>>>>> what does it mean exactly ?
>>>>>>> Should we not sum up all the receiver for each
>>>>>>> VariantMetricInformation and from there get the top 3 ? Not sure this is
>>>>>>> happening right now, maybe @matzew or @edewit could give more info.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius <
>>>>>>> daniel.bevenius at gmail.com> wrote:
>>>>>>>
>>>>>>>> Sorry, looking into this and I can't see any easy fix.
>>>>>>>> The problem as I see it is that the for the same variantId there
>>>>>>>> can be multiple receivers. But we currently don't know which
>>>>>>>> ApplicationVariant the receivers belong to. So we cannot match them up in
>>>>>>>> DashBoardService.
>>>>>>>> This my first time looking at the code so I might be missing
>>>>>>>> something. So I'd say your first post about the query being wrong is
>>>>>>>> correct, and we have to take the match the VariantMetricInformation and
>>>>>>>> match it with a pushApplicationId. Again, I could be way off here :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 31 July 2014 10:47, Daniel Bevenius <daniel.bevenius at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey Seb,
>>>>>>>>>
>>>>>>>>> sure let me take a closer look at this. I'm getting the feeling
>>>>>>>>> that it might not be as simple as that. Let me push something and we can
>>>>>>>>> discuss it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 31 July 2014 10:39, Sebastien Blanc <scm.blanc at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Dan,
>>>>>>>>>> Not sure if I understand exactly what you meant, could do a small
>>>>>>>>>> snippet ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius <
>>>>>>>>>> daniel.bevenius at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Oh I see. Then I'd say you'll need to change the return type to
>>>>>>>>>>> either use a custom object for the key in the map, or perhaps return a list
>>>>>>>>>>> with that came custom object. What ever makes the most sense in this use
>>>>>>>>>>> case. Makes sense?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 31 July 2014 09:39, Sebastien Blanc <scm.blanc at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Well, several VariantMetricInformation instances can have the
>>>>>>>>>>>> same VariantID, at each send , one is created :
>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius <
>>>>>>>>>>>> daniel.bevenius at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Is this because variantFour and variantFive have the same
>>>>>>>>>>>>> variantId (231543432434)? When added to the map only one will exist later
>>>>>>>>>>>>> in findTopThreeBusyVariantIDs.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc <scm.blanc at gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Morning Peeps,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm currently trying to fix AGPUSH-848[1].
>>>>>>>>>>>>>> Basically, the number of receivers shown in the top3 list is
>>>>>>>>>>>>>> not always accurate.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I suspect that something is wrong with this query :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have change this test case :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> By adding just one VariantInformation[2] and now the test is
>>>>>>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm probably missing something obvious but I can not see it
>>>>>>>>>>>>>> right now :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sebi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848
>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/f2b72db7/attachment-0001.html
More information about the aerogear-dev
mailing list