On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf <matzew(a)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 ?
On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc <scm.blanc(a)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(a)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(a)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(a)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(a)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(a)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%...
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius <
>>>>>> daniel.bevenius(a)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(a)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...
>>>>>>>>
>>>>>>>> I have change this test case :
>>>>>>>>
>>>>>>>>
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model...
>>>>>>>>
>>>>>>>> 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-gistfile...
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> aerogear-dev mailing list
>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev