From matzew at apache.org  Tue May  9 10:14:39 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 9 May 2017 16:14:39 +0200
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
Message-ID: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>

Hello AeroGear community,

as the AeroGear project lead, I am thrilled to announce that this year we
do have two students working on the AeroGear UnifiedPush server, during the
Google Summer of Code Projects.

Both students applied to the "Apache Kafka and Apache HBase" improvements
project, and did deliver a great paper and detailed implementation plan.

Over the summer Dimitra and Polina will work with us, in the open, in the
community on this project.

The main access point for our community is listed here. Most of us do hang
around on IRC, and of course, if there are questions, please send mails to
our mailing list.

Details:
https://aerogear.org/community/


Dimitra, and Polina, I'd like to ask you to introduce yourself here on this
mailing list (remember to subscribe for it), so that the larger AeroGear
community gets to know you better!

Cheers,
Matthias


-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170509/1a8efc6e/attachment.html 

From jgallaso at redhat.com  Tue May  9 10:58:53 2017
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Tue, 9 May 2017 16:58:53 +0200
Subject: [aerogear-dev] Stream of Exceptions in log when using fake data
Message-ID: <CAGsbZmFPxwLtwW7FYxOWSAbyp36e9KBJwTrKJjY_8pyVs5QLeQ@mail.gmail.com>

Hi all,

I am playing a bit with the admin-ui and added some fake variant. When
trying to send a notification, a 500 Error popup showed up and the terminal
spat out a couple of ugly Exceptions ->
https://gist.github.com/josemigallas/614a7ffe01e213b25470bfa11925a365

What I did is create a new Android variant with some madeup senderId and
serverKey and then add some fake tokens with the mock-data-loader
<https://github.com/aerogear/ups-test-suite/tree/master/mock-data-loader>.

I don't really know if this is some kind of error but I wouldn't expect so
many Exceptions. It should simply check the response from FCM, not throwing
exceptions here and there. Maybe it has nothing to do with it and I am just
doing something else wrong.

WDYT?

Cheers,

-- 

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170509/99cded56/attachment.html 

From matzew at apache.org  Tue May  9 11:08:00 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 9 May 2017 17:08:00 +0200
Subject: [aerogear-dev] Fwd: Google summer of code: WELCOME Dimitra and
	Polina
In-Reply-To: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
Message-ID: <CAAg5f2QVz-3oWXgNcAkuqf5Xypg5KPLewmZ4RdvanEhD+xt84w@mail.gmail.com>

---------- Forwarded message ----------
From: Matthias Wessendorf <matzew at apache.org>
Date: Tue, May 9, 2017 at 4:14 PM
Subject: Google summer of code: WELCOME Dimitra and Polina
To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
Cc: Dimitra Zuccarelli <dimitrazuccarelli at gmail.com>, Polina Koleva <
polina.n.koleva at gmail.com>


Hello AeroGear community,

as the AeroGear project lead, I am thrilled to announce that this year we
do have two students working on the AeroGear UnifiedPush server, during the
Google Summer of Code Projects.

Both students applied to the "Apache Kafka and Apache HBase" improvements
project, and did deliver a great paper and detailed implementation plan.

Over the summer Dimitra and Polina will work with us, in the open, in the
community on this project.

The main access point for our community is listed here. Most of us do hang
around on IRC, and of course, if there are questions, please send mails to
our mailing list.

Details:
https://aerogear.org/community/


Dimitra, and Polina, I'd like to ask you to introduce yourself here on this
mailing list (remember to subscribe for it), so that the larger AeroGear
community gets to know you better!

Cheers,
Matthias


-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170509/bd76af37/attachment.html 

From lgriffin at redhat.com  Tue May  9 12:40:54 2017
From: lgriffin at redhat.com (Leigh Griffin)
Date: Tue, 9 May 2017 17:40:54 +0100
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
Message-ID: <CAOQ+WrpA_Fb3TKpNYx-ksYpJzHDNu6SkhiWbJ7hoSL2aj6uTSw@mail.gmail.com>

Great to have you both on board and really looking forward to the next few
months :)

On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello AeroGear community,
>
> as the AeroGear project lead, I am thrilled to announce that this year we
> do have two students working on the AeroGear UnifiedPush server, during the
> Google Summer of Code Projects.
>
> Both students applied to the "Apache Kafka and Apache HBase" improvements
> project, and did deliver a great paper and detailed implementation plan.
>
> Over the summer Dimitra and Polina will work with us, in the open, in the
> community on this project.
>
> The main access point for our community is listed here. Most of us do hang
> around on IRC, and of course, if there are questions, please send mails to
> our mailing list.
>
> Details:
> https://aerogear.org/community/
>
>
> Dimitra, and Polina, I'd like to ask you to introduce yourself here on
> this mailing list (remember to subscribe for it), so that the larger
> AeroGear community gets to know you better!
>
> Cheers,
> Matthias
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland <https://www.redhat.com/>

Communications House, Cork Road

Waterford City, Ireland X91NY33

lgriffin at redhat.com    M: +353877545162     IM: lgriffin
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

@redhatway <https://twitter.com/redhatway>   @redhatinc
<https://instagram.com/redhatinc>   @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170509/e475f2b9/attachment-0001.html 

From matzew at apache.org  Tue May  9 13:39:57 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 9 May 2017 19:39:57 +0200
Subject: [aerogear-dev] Stream of Exceptions in log when using fake data
In-Reply-To: <CAGsbZmFPxwLtwW7FYxOWSAbyp36e9KBJwTrKJjY_8pyVs5QLeQ@mail.gmail.com>
References: <CAGsbZmFPxwLtwW7FYxOWSAbyp36e9KBJwTrKJjY_8pyVs5QLeQ@mail.gmail.com>
Message-ID: <CAAg5f2RTCAbZ-CsKd0MdpbRQAT8W0=YTBzYy-kOPrQC1Nk0cKw@mail.gmail.com>

Let me guess: you reuse a DB from the 1.1.x testing, but run with master ?
I see undertow, which is WildFly, and only supported on master

the DB schema for 1.1.x branch (the one we test w/ EAP) is different than
the one in master (the one we test w/ WildFly)

NOTE: the master code does NOT yet contain the APNs/HTTP2 fixes. I had no
time to port that forward

On Tue, May 9, 2017 at 4:58 PM, Jose Miguel Gallas Olmedo <
jgallaso at redhat.com> wrote:

> Hi all,
>
> I am playing a bit with the admin-ui and added some fake variant. When
> trying to send a notification, a 500 Error popup showed up and the terminal
> spat out a couple of ugly Exceptions -> https://gist.github.com/
> josemigallas/614a7ffe01e213b25470bfa11925a365
>
> What I did is create a new Android variant with some madeup senderId and
> serverKey and then add some fake tokens with the mock-data-loader
> <https://github.com/aerogear/ups-test-suite/tree/master/mock-data-loader>.
>
> I don't really know if this is some kind of error but I wouldn't expect so
> many Exceptions. It should simply check the response from FCM, not throwing
> exceptions here and there. Maybe it has nothing to do with it and I am just
> doing something else wrong.
>
> WDYT?
>
> Cheers,
>
> --
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170509/3f00ce53/attachment.html 

From polina.n.koleva at gmail.com  Tue May  9 14:32:15 2017
From: polina.n.koleva at gmail.com (Polina Koleva)
Date: Tue, 9 May 2017 11:32:15 -0700 (MST)
Subject: [aerogear-dev] Fwd: Google summer of code: WELCOME Dimitra and
 Polina
In-Reply-To: <CAAg5f2QVz-3oWXgNcAkuqf5Xypg5KPLewmZ4RdvanEhD+xt84w@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAAg5f2QVz-3oWXgNcAkuqf5Xypg5KPLewmZ4RdvanEhD+xt84w@mail.gmail.com>
Message-ID: <1494354735848-12955.post@n5.nabble.com>

Hello everyone, 
I am Polina Koleva, 26 years old Bulgarian national :) Currently, I am doing
my Masters degree in Computer Science in Freiburg, Germany. I am almost
finishing my second year and after the current semester, the only thing left
is my master thesis. I have interests in algorithms, design patterns and big
data technologies as Hadoop, MapReduce, Spark, Impala and etc. Additionally,
this semester I will try to gain more knowledge in the field of artificial
intelligence, robotics and machine learning, Professionally, I was working
for more than 4 years as Java developer. 

I am really glad that I will be part of the community and really excited
about improvements which we will be implementing during the summer. Hope we
will be a valuable asset to the team.

Looking forward to working together.

Best Regards,
Polina Koleva :)




--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12955.html
Sent from the aerogear-dev mailing list archive at Nabble.com.

From jgallaso at redhat.com  Wed May 10 03:45:59 2017
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Wed, 10 May 2017 09:45:59 +0200
Subject: [aerogear-dev] Stream of Exceptions in log when using fake data
In-Reply-To: <CAAg5f2RTCAbZ-CsKd0MdpbRQAT8W0=YTBzYy-kOPrQC1Nk0cKw@mail.gmail.com>
References: <CAGsbZmFPxwLtwW7FYxOWSAbyp36e9KBJwTrKJjY_8pyVs5QLeQ@mail.gmail.com>
	<CAAg5f2RTCAbZ-CsKd0MdpbRQAT8W0=YTBzYy-kOPrQC1Nk0cKw@mail.gmail.com>
Message-ID: <CAGsbZmEyWbjr85Vy5CojbKyc-EBcAR08QkZAazTAN-GxOYZgrQ@mail.gmail.com>

Hi Matthias,

No, I'm using 1.1.x-dev all the time, I just checked it again. I didn't do
anything with the DB though, is it necessary to update it as well?

Cheers,

On 9 May 2017 at 19:39, Matthias Wessendorf <matzew at apache.org> wrote:

> Let me guess: you reuse a DB from the 1.1.x testing, but run with master ?
> I see undertow, which is WildFly, and only supported on master
>
> the DB schema for 1.1.x branch (the one we test w/ EAP) is different than
> the one in master (the one we test w/ WildFly)
>
> NOTE: the master code does NOT yet contain the APNs/HTTP2 fixes. I had no
> time to port that forward
>
> On Tue, May 9, 2017 at 4:58 PM, Jose Miguel Gallas Olmedo <
> jgallaso at redhat.com> wrote:
>
>> Hi all,
>>
>> I am playing a bit with the admin-ui and added some fake variant. When
>> trying to send a notification, a 500 Error popup showed up and the terminal
>> spat out a couple of ugly Exceptions -> https://gist.github.com/jos
>> emigallas/614a7ffe01e213b25470bfa11925a365
>>
>> What I did is create a new Android variant with some madeup senderId and
>> serverKey and then add some fake tokens with the mock-data-loader
>> <https://github.com/aerogear/ups-test-suite/tree/master/mock-data-loader>
>> .
>>
>> I don't really know if this is some kind of error but I wouldn't expect
>> so many Exceptions. It should simply check the response from FCM, not
>> throwing exceptions here and there. Maybe it has nothing to do with it and
>> I am just doing something else wrong.
>>
>> WDYT?
>>
>> Cheers,
>>
>> --
>>
>> JOSE MIGUEL GALLAS OLMEDO
>>
>> ASSOCIATE QE, mobile
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>>
>> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> 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/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170510/6cf099d2/attachment.html 

From matzew at apache.org  Wed May 10 04:20:15 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 10 May 2017 08:20:15 +0000
Subject: [aerogear-dev] Stream of Exceptions in log when using fake data
In-Reply-To: <CAGsbZmEyWbjr85Vy5CojbKyc-EBcAR08QkZAazTAN-GxOYZgrQ@mail.gmail.com>
References: <CAGsbZmFPxwLtwW7FYxOWSAbyp36e9KBJwTrKJjY_8pyVs5QLeQ@mail.gmail.com>
	<CAAg5f2RTCAbZ-CsKd0MdpbRQAT8W0=YTBzYy-kOPrQC1Nk0cKw@mail.gmail.com>
	<CAGsbZmEyWbjr85Vy5CojbKyc-EBcAR08QkZAazTAN-GxOYZgrQ@mail.gmail.com>
Message-ID: <CAAg5f2Qox-beNsUbRS-m_=2BPSeRroz+35rS+9gkHoQUrJuxow@mail.gmail.com>

Ah, good :-)

undertow in stack trace tells me you use WildFly.

Please use EAP 6.4.x (.11 for instance) with 1.1.x


On Wed, 10 May 2017 at 09:46, Jose Miguel Gallas Olmedo <jgallaso at redhat.com>
wrote:

> Hi Matthias,
>
> No, I'm using 1.1.x-dev all the time, I just checked it again. I didn't do
> anything with the DB though, is it necessary to update it as well?
>
> Cheers,
>
> On 9 May 2017 at 19:39, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> Let me guess: you reuse a DB from the 1.1.x testing, but run with master
>> ? I see undertow, which is WildFly, and only supported on master
>>
>> the DB schema for 1.1.x branch (the one we test w/ EAP) is different than
>> the one in master (the one we test w/ WildFly)
>>
>> NOTE: the master code does NOT yet contain the APNs/HTTP2 fixes. I had no
>> time to port that forward
>>
>> On Tue, May 9, 2017 at 4:58 PM, Jose Miguel Gallas Olmedo <
>> jgallaso at redhat.com> wrote:
>>
>>> Hi all,
>>>
>>> I am playing a bit with the admin-ui and added some fake variant. When
>>> trying to send a notification, a 500 Error popup showed up and the terminal
>>> spat out a couple of ugly Exceptions ->
>>> https://gist.github.com/josemigallas/614a7ffe01e213b25470bfa11925a365
>>>
>>> What I did is create a new Android variant with some madeup senderId and
>>> serverKey and then add some fake tokens with the mock-data-loader
>>> <https://github.com/aerogear/ups-test-suite/tree/master/mock-data-loader>
>>> .
>>>
>>> I don't really know if this is some kind of error but I wouldn't expect
>>> so many Exceptions. It should simply check the response from FCM, not
>>> throwing exceptions here and there. Maybe it has nothing to do with it and
>>> I am just doing something else wrong.
>>>
>>> WDYT?
>>>
>>> Cheers,
>>>
>>> --
>>>
>>> JOSE MIGUEL GALLAS OLMEDO
>>>
>>> ASSOCIATE QE, mobile
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com/>
>>>
>>> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>>>
>>> <https://red.ht/sig>
>>>
>>> _______________________________________________
>>> 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/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170510/476e5d05/attachment-0001.html 

From jgallaso at redhat.com  Wed May 10 04:42:29 2017
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Wed, 10 May 2017 10:42:29 +0200
Subject: [aerogear-dev] Fwd: Google summer of code: WELCOME Dimitra and
	Polina
In-Reply-To: <1494354735848-12955.post@n5.nabble.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAAg5f2QVz-3oWXgNcAkuqf5Xypg5KPLewmZ4RdvanEhD+xt84w@mail.gmail.com>
	<1494354735848-12955.post@n5.nabble.com>
Message-ID: <CAGsbZmGT-Hs9t88m_S1ay-EBfZa18dc3xpGxduAUGxK-P0nhYw@mail.gmail.com>

Nice to hear that! Welcome Dimitra and Polina, can't wait to rock the
*shell* out of AeroGear with you guys! ??

On 9 May 2017 at 20:32, Polina Koleva <polina.n.koleva at gmail.com> wrote:

> Hello everyone,
> I am Polina Koleva, 26 years old Bulgarian national :) Currently, I am
> doing
> my Masters degree in Computer Science in Freiburg, Germany. I am almost
> finishing my second year and after the current semester, the only thing
> left
> is my master thesis. I have interests in algorithms, design patterns and
> big
> data technologies as Hadoop, MapReduce, Spark, Impala and etc.
> Additionally,
> this semester I will try to gain more knowledge in the field of artificial
> intelligence, robotics and machine learning, Professionally, I was working
> for more than 4 years as Java developer.
>
> I am really glad that I will be part of the community and really excited
> about improvements which we will be implementing during the summer. Hope we
> will be a valuable asset to the team.
>
> Looking forward to working together.
>
> Best Regards,
> Polina Koleva :)
>
>
>
>
> --
> View this message in context: http://aerogear-dev.1069024.
> n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-
> Dimitra-and-Polina-tp12952p12955.html
> Sent from the aerogear-dev mailing list archive at Nabble.com.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170510/68c731e7/attachment.html 

From dimitrazuccarelli at gmail.com  Wed May 10 13:23:21 2017
From: dimitrazuccarelli at gmail.com (Dimitra Zuccarelli)
Date: Wed, 10 May 2017 18:23:21 +0100
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
Message-ID: <CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>

Hi everyone,

I'm Dimitra, 21 years old from South Africa/Italy. Im currently studying
Applied Computing in Waterford, Ireland. I love programming and similarly
to Polina I'm most interested in algorithms, big data and trend analysis.

I can't wait to start work on this project and I'm looking forward to
getting more involved in the community!

On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hello AeroGear community,
>
> as the AeroGear project lead, I am thrilled to announce that this year we
> do have two students working on the AeroGear UnifiedPush server, during the
> Google Summer of Code Projects.
>
> Both students applied to the "Apache Kafka and Apache HBase" improvements
> project, and did deliver a great paper and detailed implementation plan.
>
> Over the summer Dimitra and Polina will work with us, in the open, in the
> community on this project.
>
> The main access point for our community is listed here. Most of us do hang
> around on IRC, and of course, if there are questions, please send mails to
> our mailing list.
>
> Details:
> https://aerogear.org/community/
>
>
> Dimitra, and Polina, I'd like to ask you to introduce yourself here on
> this mailing list (remember to subscribe for it), so that the larger
> AeroGear community gets to know you better!
>
> Cheers,
> Matthias
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170510/0d29bcd0/attachment.html 

From matzew at apache.org  Thu May 11 05:56:50 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 11 May 2017 11:56:50 +0200
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
Message-ID: <CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>

Hi, Polina and Dimitra,

thanks for the nice introduction. The first weeks for Google Summer of Code
are usually about community bonding: Get to know your community, chat w/
people on IRC, check out the code base of the UPS, try examples, ask
quesions on mail or on IRC.

It's perhaps also a good idea to get a bit of sense of Apache Kafka,
especially for stream processing.

Here is a good intro on Kafka, and Kafka-Streams, and why Spark/Flink etc
are not always needed ;-)
https://balamaci.ro/kafka-streams-for-stream-processing/

I hope you will enjoy the work over the summer! :-)
Cheers,
Matthias



On Wed, May 10, 2017 at 7:23 PM, Dimitra Zuccarelli <
dimitrazuccarelli at gmail.com> wrote:

> Hi everyone,
>
> I'm Dimitra, 21 years old from South Africa/Italy. Im currently studying
> Applied Computing in Waterford, Ireland. I love programming and similarly
> to Polina I'm most interested in algorithms, big data and trend analysis.
>
> I can't wait to start work on this project and I'm looking forward to
> getting more involved in the community!
>
> On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hello AeroGear community,
>>
>> as the AeroGear project lead, I am thrilled to announce that this year we
>> do have two students working on the AeroGear UnifiedPush server, during the
>> Google Summer of Code Projects.
>>
>> Both students applied to the "Apache Kafka and Apache HBase" improvements
>> project, and did deliver a great paper and detailed implementation plan.
>>
>> Over the summer Dimitra and Polina will work with us, in the open, in the
>> community on this project.
>>
>> The main access point for our community is listed here. Most of us do
>> hang around on IRC, and of course, if there are questions, please send
>> mails to our mailing list.
>>
>> Details:
>> https://aerogear.org/community/
>>
>>
>> Dimitra, and Polina, I'd like to ask you to introduce yourself here on
>> this mailing list (remember to subscribe for it), so that the larger
>> AeroGear community gets to know you better!
>>
>> Cheers,
>> Matthias
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170511/ab92aa6d/attachment.html 

From aliok at redhat.com  Thu May 11 07:20:00 2017
From: aliok at redhat.com (Ali Ok)
Date: Thu, 11 May 2017 14:20:00 +0300
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
	<CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>
Message-ID: <CABoO8Leen1Tsd0pC8X4_4ORK+h44sYMePprmDELd+jDvVn6kSg@mail.gmail.com>

Hi, Polina and Dimitra,

Welcome onboard!

I was a GSoC student in 2010 and I must tell you it is a great opportunity
to work with the best open source communities.
I am sure you will both graduate from this program successfully.

Cheers,
Ali


On Thu, May 11, 2017 at 12:56 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi, Polina and Dimitra,
>
> thanks for the nice introduction. The first weeks for Google Summer of
> Code are usually about community bonding: Get to know your community, chat
> w/ people on IRC, check out the code base of the UPS, try examples, ask
> quesions on mail or on IRC.
>
> It's perhaps also a good idea to get a bit of sense of Apache Kafka,
> especially for stream processing.
>
> Here is a good intro on Kafka, and Kafka-Streams, and why Spark/Flink etc
> are not always needed ;-)
> https://balamaci.ro/kafka-streams-for-stream-processing/
>
> I hope you will enjoy the work over the summer! :-)
> Cheers,
> Matthias
>
>
>
> On Wed, May 10, 2017 at 7:23 PM, Dimitra Zuccarelli <
> dimitrazuccarelli at gmail.com> wrote:
>
>> Hi everyone,
>>
>> I'm Dimitra, 21 years old from South Africa/Italy. Im currently studying
>> Applied Computing in Waterford, Ireland. I love programming and similarly
>> to Polina I'm most interested in algorithms, big data and trend analysis.
>>
>> I can't wait to start work on this project and I'm looking forward to
>> getting more involved in the community!
>>
>> On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hello AeroGear community,
>>>
>>> as the AeroGear project lead, I am thrilled to announce that this year
>>> we do have two students working on the AeroGear UnifiedPush server, during
>>> the Google Summer of Code Projects.
>>>
>>> Both students applied to the "Apache Kafka and Apache HBase"
>>> improvements project, and did deliver a great paper and detailed
>>> implementation plan.
>>>
>>> Over the summer Dimitra and Polina will work with us, in the open, in
>>> the community on this project.
>>>
>>> The main access point for our community is listed here. Most of us do
>>> hang around on IRC, and of course, if there are questions, please send
>>> mails to our mailing list.
>>>
>>> Details:
>>> https://aerogear.org/community/
>>>
>>>
>>> Dimitra, and Polina, I'd like to ask you to introduce yourself here on
>>> this mailing list (remember to subscribe for it), so that the larger
>>> AeroGear community gets to know you better!
>>>
>>> Cheers,
>>> Matthias
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>> _______________________________________________
>> 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/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

ALI OK

SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM

Red Hat

<https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170511/6fe690c2/attachment-0001.html 

From dimitrazuccarelli at gmail.com  Thu May 11 16:55:28 2017
From: dimitrazuccarelli at gmail.com (Dimitra)
Date: Thu, 11 May 2017 13:55:28 -0700 (MST)
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CABoO8Leen1Tsd0pC8X4_4ORK+h44sYMePprmDELd+jDvVn6kSg@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
	<CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>
	<CABoO8Leen1Tsd0pC8X4_4ORK+h44sYMePprmDELd+jDvVn6kSg@mail.gmail.com>
Message-ID: <C075CF0E-76FB-4E34-AED4-E2F8E1A1B67A@gmail.com>

Hi Ali thanks so much! 

It's such an exciting opportunity and I'm really grateful to be a part of it.

With who (whom?) did you do your project and what was it on? 

> On 11 May 2017, at 19:17, Ali Ok [via aerogear-dev] <ml+s1069024n12962h81 at n5.nabble.com> wrote:
> 
> Hi, Polina and Dimitra,
> 
> Welcome onboard!
> 
> I was a GSoC student in 2010 and I must tell you it is a great opportunity to work with the best open source communities.
> I am sure you will both graduate from this program successfully.
> 
> Cheers,
> Ali
> 
> 
>> On Thu, May 11, 2017 at 12:56 PM, Matthias Wessendorf <[hidden email]> wrote:
>> Hi, Polina and Dimitra,
>> 
>> thanks for the nice introduction. The first weeks for Google Summer of Code are usually about community bonding: Get to know your community, chat w/ people on IRC, check out the code base of the UPS, try examples, ask quesions on mail or on IRC.
>> 
>> It's perhaps also a good idea to get a bit of sense of Apache Kafka, especially for stream processing. 
>> 
>> Here is a good intro on Kafka, and Kafka-Streams, and why Spark/Flink etc are not always needed ;-)  
>> https://balamaci.ro/kafka-streams-for-stream-processing/
>> 
>> I hope you will enjoy the work over the summer! :-)
>> Cheers,
>> Matthias
>> 
>> 
>> 
>>> On Wed, May 10, 2017 at 7:23 PM, Dimitra Zuccarelli <[hidden email]> wrote:
>>> Hi everyone, 
>>> 
>>> I'm Dimitra, 21 years old from South Africa/Italy. Im currently studying Applied Computing in Waterford, Ireland. I love programming and similarly to Polina I'm most interested in algorithms, big data and trend analysis. 
>>> 
>>> I can't wait to start work on this project and I'm looking forward to getting more involved in the community!
>>> 
>>>> On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <[hidden email]> wrote:
>>> 
>>>> Hello AeroGear community,
>>>> 
>>>> as the AeroGear project lead, I am thrilled to announce that this year we do have two students working on the AeroGear UnifiedPush server, during the Google Summer of Code Projects.
>>>> 
>>>> Both students applied to the "Apache Kafka and Apache HBase" improvements project, and did deliver a great paper and detailed implementation plan.
>>>> 
>>>> Over the summer Dimitra and Polina will work with us, in the open, in the community on this project. 
>>>> 
>>>> The main access point for our community is listed here. Most of us do hang around on IRC, and of course, if there are questions, please send mails to our mailing list.
>>>> 
>>>> Details:
>>>> https://aerogear.org/community/
>>>> 
>>>> 
>>>> Dimitra, and Polina, I'd like to ask you to introduce yourself here on this mailing list (remember to subscribe for it), so that the larger AeroGear community gets to know you better!
>>>> 
>>>> Cheers,
>>>> Matthias
>>>> 
>>>> 
>>>> -- 
>>>> Matthias Wessendorf 
>>>> 
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> twitter: http://twitter.com/mwessendorf
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> 
>> -- 
>> Matthias Wessendorf 
>> 
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> ALI OK
> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
> Red Hat 
> 
> 
> 
> _______________________________________________ 
> aerogear-dev mailing list 
> [hidden email] 
> https://lists.jboss.org/mailman/listinfo/aerogear-dev 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12962.html
> To start a new topic under aerogear-dev, email ml+s1069024n1h90 at n5.nabble.com 
> To unsubscribe from aerogear-dev, click here.
> NAML




--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12964.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170511/27f19f69/attachment.html 

From matzew at apache.org  Tue May 16 04:48:29 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 16 May 2017 10:48:29 +0200
Subject: [aerogear-dev] UPS 1.2.0-beta.1 release
Message-ID: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>

Hi,

after a long time, we are running a new release of the master branch:
1.2.0-beta.1

Most important fixes were around memory leaks and improving poor APNs
connection handling.
Also, internally we are now connecting against the HTTP/2 endpoints from
APNs, as THE hightligh of this stability release, hence also moving to
'beta'

Details can be found here:
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313724&version=12334702


the staging repository is located here:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-11183/

Once the release is out, I will update our docker images

Cheers!
Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/f4a1cb34/attachment.html 

From matzew at apache.org  Tue May 16 07:58:25 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 16 May 2017 13:58:25 +0200
Subject: [aerogear-dev] Notification Delivery metrics and processing with
	Kafka
Message-ID: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>

Hi,

with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get a
way more finegrain knowledge if Apple did accept (for further processing)
or reject a messages, on a per device_token level!

For instance, if we have a push with 5000 targeted devices, we are now able
to say that 5 tokens, for instances failed, but APNs was happy to accept
push request for the other 4995 devices (Note: this does NOT mean they
actually arrive at the device, just that apple accepted them for further
processing).

Now, this, for APNs, gives us much more flexiblity handling our metrics!

In our code, here, we do read *each* token request from APNs in here:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/20831d96196663349c96da6b5fe11aef65cacf59/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/apns/PushyApnsSender.java#L130-L147

So here, we could simply send the result, on a per token base, to a (Kafka)
topic, like:

...
if (pushNotificationResponse.isAccepted()) {
  logger.trace("Push notification for '{}' (payload={})", deviceToken,
pushNotificationResponse.getPushNotification().getPayload());

  producer.send(jobID, "Success"); // sends to "push_messages" topic
} else {
  final String rejectReason = pushNotificationResponse.getRejectionReason();
  logger.trace("Push Message has been rejected with reason: {}", rejectReason);

  producer.send(jobID, "Rejected"); // sends "push_messages" topic
...
}

Now, this sends all to one topic, and we could be using, somewhere, Kafka
Stream API, to perform some processing of the source, and calculate some
stats on that, like:

KStreamBuilder builder = new KStreamBuilder();

// read from the topic that contains all messages, for all jobs
final KStream<String, String> source = builder.stream("push_messages");


// some simple processing, and grouping by key, applying a predicate
and send to three "analytic" topic:

final KTable<String, Long> successCountsPerJob = source.filter((key,
value) -> value.equals("Success"))
  .groupByKey()
  .count("successMessagesPerJob");
successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");

final KTable<String, Long> failCountsPerJob = source.filter((key,
value) -> value.equals("Rejected"))
  .groupByKey()
  .count("failedMessagesPerJob");
failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");

source.groupByKey()
  count("totalMessagesPerJob")
    .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");


The above performs some functional processing of the single source of
truth, based on different assumptions.

If one would have a simple consumer on each of these three "analytic"
topics, a simple logging output would be:

2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX
2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX
2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX


since for the GSoC we do have two students, working on Kafka and HBase
improvements for UPS, I wanted to share this quick prototype, as food for
thoughts.

Of course, each of these 'filtered' consumers could than eventually store
the result somewhere else.

With this approach, Kafka would be come the hub (or data pipeline) for our
metrics, with stream processing and different consumers to deal with the
results of interest

Any comments or other thoughts?

-Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/6b5d646d/attachment-0001.html 

From aliok at redhat.com  Tue May 16 08:22:50 2017
From: aliok at redhat.com (Ali Ok)
Date: Tue, 16 May 2017 15:22:50 +0300
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <C075CF0E-76FB-4E34-AED4-E2F8E1A1B67A@gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
	<CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>
	<CABoO8Leen1Tsd0pC8X4_4ORK+h44sYMePprmDELd+jDvVn6kSg@mail.gmail.com>
	<C075CF0E-76FB-4E34-AED4-E2F8E1A1B67A@gmail.com>
Message-ID: <CABoO8LexrphgqCyV6oW18W0TMzeqi5+7zSH2LU4euwDdy861Ow@mail.gmail.com>

Hi,

My mentor was Mr. Matzew, similar to you both :)
I was doing the project within Apache Software Foundation. I mostly
experimented with HTML5 (which was a new thing back then) and created a JSF
component library under Apache Myfaces.
I became an Apache committer when the project was finished.

It was fun!

Cheers,
Ali

On Thu, May 11, 2017 at 11:55 PM, Dimitra <dimitrazuccarelli at gmail.com>
wrote:

> Hi Ali thanks so much!
>
> It's such an exciting opportunity and I'm really grateful to be a part of
> it.
>
> With who (whom?) did you do your project and what was it on?
>
> On 11 May 2017, at 19:17, Ali Ok [via aerogear-dev] <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=12964&i=0>> wrote:
>
> Hi, Polina and Dimitra,
>
> Welcome onboard!
>
> I was a GSoC student in 2010 and I must tell you it is a great opportunity
> to work with the best open source communities.
> I am sure you will both graduate from this program successfully.
>
> Cheers,
> Ali
>
>
> On Thu, May 11, 2017 at 12:56 PM, Matthias Wessendorf <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=12962&i=0>> wrote:
>
>> Hi, Polina and Dimitra,
>>
>> thanks for the nice introduction. The first weeks for Google Summer of
>> Code are usually about community bonding: Get to know your community, chat
>> w/ people on IRC, check out the code base of the UPS, try examples, ask
>> quesions on mail or on IRC.
>>
>> It's perhaps also a good idea to get a bit of sense of Apache Kafka,
>> especially for stream processing.
>>
>> Here is a good intro on Kafka, and Kafka-Streams, and why Spark/Flink etc
>> are not always needed ;-)
>> https://balamaci.ro/kafka-streams-for-stream-processing/
>>
>> I hope you will enjoy the work over the summer! :-)
>> Cheers,
>> Matthias
>>
>>
>>
>> On Wed, May 10, 2017 at 7:23 PM, Dimitra Zuccarelli <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=12962&i=1>> wrote:
>>
>>> Hi everyone,
>>>
>>> I'm Dimitra, 21 years old from South Africa/Italy. Im currently studying
>>> Applied Computing in Waterford, Ireland. I love programming and similarly
>>> to Polina I'm most interested in algorithms, big data and trend analysis.
>>>
>>> I can't wait to start work on this project and I'm looking forward to
>>> getting more involved in the community!
>>>
>>> On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=12962&i=2>> wrote:
>>>
>>>> Hello AeroGear community,
>>>>
>>>> as the AeroGear project lead, I am thrilled to announce that this year
>>>> we do have two students working on the AeroGear UnifiedPush server, during
>>>> the Google Summer of Code Projects.
>>>>
>>>> Both students applied to the "Apache Kafka and Apache HBase"
>>>> improvements project, and did deliver a great paper and detailed
>>>> implementation plan.
>>>>
>>>> Over the summer Dimitra and Polina will work with us, in the open, in
>>>> the community on this project.
>>>>
>>>> The main access point for our community is listed here. Most of us do
>>>> hang around on IRC, and of course, if there are questions, please send
>>>> mails to our mailing list.
>>>>
>>>> Details:
>>>> https://aerogear.org/community/
>>>>
>>>>
>>>> Dimitra, and Polina, I'd like to ask you to introduce yourself here on
>>>> this mailing list (remember to subscribe for it), so that the larger
>>>> AeroGear community gets to know you better!
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=3>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=4>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> ALI OK
>
> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
>
> Red Hat
>
> <https://www.redhat.com/>
> <https://red.ht/sig>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=5>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-
> Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12962.html
> To start a new topic under aerogear-dev, email [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=12964&i=1>
> To unsubscribe from aerogear-dev, click here.
> NAML
> <http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
>
> ------------------------------
> View this message in context: Re: [aerogear-dev] Google summer of code:
> WELCOME Dimitra and Polina
> <http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12964.html>
> Sent from the aerogear-dev mailing list archive
> <http://aerogear-dev.1069024.n5.nabble.com/> at Nabble.com.
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

ALI OK

SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM

Red Hat

<https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/90a2cb85/attachment.html 

From supittma at redhat.com  Tue May 16 08:49:21 2017
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 16 May 2017 08:49:21 -0400
Subject: [aerogear-dev] UPS 1.2.0-beta.1 release
In-Reply-To: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
References: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
Message-ID: <CAEQz2CuFRk4_rSrhUHC_uVuqd9+c7PcP=H1uu4HCqX+kKeS3Vg@mail.gmail.com>

Yay!

What can we test out if all we have is Android?

On Tue, May 16, 2017 at 4:48 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> after a long time, we are running a new release of the master branch:
> 1.2.0-beta.1
>
> Most important fixes were around memory leaks and improving poor APNs
> connection handling.
> Also, internally we are now connecting against the HTTP/2 endpoints from
> APNs, as THE hightligh of this stability release, hence also moving to
> 'beta'
>
> Details can be found here:
> https://issues.jboss.org/secure/ReleaseNote.jspa?
> projectId=12313724&version=12334702
>
>
> the staging repository is located here:
> https://repository.jboss.org/nexus/content/repositories/
> jboss_releases_staging_profile-11183/
>
> Once the release is out, I will update our docker images
>
> Cheers!
> Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/be61a9ec/attachment-0001.html 

From mwessend at redhat.com  Tue May 16 08:49:43 2017
From: mwessend at redhat.com (Matthias Wessendorf)
Date: Tue, 16 May 2017 14:49:43 +0200
Subject: [aerogear-dev] test
Message-ID: <CAKUFdH2dO7kfi+Vgq8B-L8d_VfwhC=-O9aGcdNw5sy36Sb8J3Q@mail.gmail.com>

test

-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/3334f1d1/attachment-0001.html 

From jgallaso at redhat.com  Tue May 16 09:37:58 2017
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Tue, 16 May 2017 15:37:58 +0200
Subject: [aerogear-dev] Notification Delivery metrics and processing
	with Kafka
In-Reply-To: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
References: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
Message-ID: <CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>

Great news!!

Will this information be displayed in the UI? As a tooltip or when
extending the row in "activity log"s table.

On 16 May 2017 at 13:58, Matthias Wessendorf <matzew at apache.org> wrote:

> Hi,
>
> with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get
> a way more finegrain knowledge if Apple did accept (for further processing)
> or reject a messages, on a per device_token level!
>
> For instance, if we have a push with 5000 targeted devices, we are now
> able to say that 5 tokens, for instances failed, but APNs was happy to
> accept push request for the other 4995 devices (Note: this does NOT mean
> they actually arrive at the device, just that apple accepted them for
> further processing).
>
> Now, this, for APNs, gives us much more flexiblity handling our metrics!
>
> In our code, here, we do read *each* token request from APNs in here:
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/
> 20831d96196663349c96da6b5fe11aef65cacf59/push/sender/src/
> main/java/org/jboss/aerogear/unifiedpush/message/sender/
> apns/PushyApnsSender.java#L130-L147
>
> So here, we could simply send the result, on a per token base, to a
> (Kafka) topic, like:
>
> ...
> if (pushNotificationResponse.isAccepted()) {
>   logger.trace("Push notification for '{}' (payload={})", deviceToken, pushNotificationResponse.getPushNotification().getPayload());
>
>   producer.send(jobID, "Success"); // sends to "push_messages" topic
> } else {
>   final String rejectReason = pushNotificationResponse.getRejectionReason();
>   logger.trace("Push Message has been rejected with reason: {}", rejectReason);
>
>   producer.send(jobID, "Rejected"); // sends "push_messages" topic
> ...
> }
>
> Now, this sends all to one topic, and we could be using, somewhere, Kafka
> Stream API, to perform some processing of the source, and calculate some
> stats on that, like:
>
> KStreamBuilder builder = new KStreamBuilder();
>
> // read from the topic that contains all messages, for all jobs
> final KStream<String, String> source = builder.stream("push_messages");
>
>
> // some simple processing, and grouping by key, applying a predicate and send to three "analytic" topic:
>
> final KTable<String, Long> successCountsPerJob = source.filter((key, value) -> value.equals("Success"))
>   .groupByKey()
>   .count("successMessagesPerJob");
> successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");
>
> final KTable<String, Long> failCountsPerJob = source.filter((key, value) -> value.equals("Rejected"))
>   .groupByKey()
>   .count("failedMessagesPerJob");
> failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");
>
> source.groupByKey()
>   count("totalMessagesPerJob")
>     .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");
>
>
> The above performs some functional processing of the single source of
> truth, based on different assumptions.
>
> If one would have a simple consumer on each of these three "analytic"
> topics, a simple logging output would be:
>
> 2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX
> 2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX
> 2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX
>
>
> since for the GSoC we do have two students, working on Kafka and HBase
> improvements for UPS, I wanted to share this quick prototype, as food for
> thoughts.
>
> Of course, each of these 'filtered' consumers could than eventually store
> the result somewhere else.
>
> With this approach, Kafka would be come the hub (or data pipeline) for our
> metrics, with stream processing and different consumers to deal with the
> results of interest
>
> Any comments or other thoughts?
>
> -Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/08958268/attachment.html 

From matzew at apache.org  Tue May 16 09:54:21 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 16 May 2017 15:54:21 +0200
Subject: [aerogear-dev] UPS 1.2.0-beta.1 release
In-Reply-To: <CAEQz2CuFRk4_rSrhUHC_uVuqd9+c7PcP=H1uu4HCqX+kKeS3Vg@mail.gmail.com>
References: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
	<CAEQz2CuFRk4_rSrhUHC_uVuqd9+c7PcP=H1uu4HCqX+kKeS3Vg@mail.gmail.com>
Message-ID: <CAAg5f2QTrXuVZEDtUcdRqBL6u8ci4NuUyH6UcSrK6DY6DnWq2w@mail.gmail.com>

normal functionality ? :-)

the biggest issue was the APNs handling code

On Tue, May 16, 2017 at 2:49 PM, Summers Pittman <supittma at redhat.com>
wrote:

> Yay!
>
> What can we test out if all we have is Android?
>
> On Tue, May 16, 2017 at 4:48 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> after a long time, we are running a new release of the master branch:
>> 1.2.0-beta.1
>>
>> Most important fixes were around memory leaks and improving poor APNs
>> connection handling.
>> Also, internally we are now connecting against the HTTP/2 endpoints from
>> APNs, as THE hightligh of this stability release, hence also moving to
>> 'beta'
>>
>> Details can be found here:
>> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=
>> 12313724&version=12334702
>>
>>
>> the staging repository is located here:
>> https://repository.jboss.org/nexus/content/repositories/jbos
>> s_releases_staging_profile-11183/
>>
>> Once the release is out, I will update our docker images
>>
>> Cheers!
>> Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/6306d370/attachment.html 

From matzew at apache.org  Tue May 16 10:50:17 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 16 May 2017 16:50:17 +0200
Subject: [aerogear-dev] Notification Delivery metrics and processing
	with Kafka
In-Reply-To: <CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>
References: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
	<CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>
Message-ID: <CAAg5f2TuPHW31ZGgyKr7epWXq5o6hbQ9eZOhujKNNPPp_Po5kw@mail.gmail.com>

Oh, this is far from being done :-)

I just did a little POC, and since we also have two GSoC students, we have
some time to define the behavior, including UI, here on the commiunity :)

On Tue, May 16, 2017 at 3:37 PM, Jose Miguel Gallas Olmedo <
jgallaso at redhat.com> wrote:

> Great news!!
>
> Will this information be displayed in the UI? As a tooltip or when
> extending the row in "activity log"s table.
>
> On 16 May 2017 at 13:58, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> Hi,
>>
>> with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get
>> a way more finegrain knowledge if Apple did accept (for further processing)
>> or reject a messages, on a per device_token level!
>>
>> For instance, if we have a push with 5000 targeted devices, we are now
>> able to say that 5 tokens, for instances failed, but APNs was happy to
>> accept push request for the other 4995 devices (Note: this does NOT mean
>> they actually arrive at the device, just that apple accepted them for
>> further processing).
>>
>> Now, this, for APNs, gives us much more flexiblity handling our metrics!
>>
>> In our code, here, we do read *each* token request from APNs in here:
>> https://github.com/aerogear/aerogear-unifiedpush-serve
>> r/blob/20831d96196663349c96da6b5fe11aef65cacf59/push/sender/
>> src/main/java/org/jboss/aerogear/unifiedpush/message/
>> sender/apns/PushyApnsSender.java#L130-L147
>>
>> So here, we could simply send the result, on a per token base, to a
>> (Kafka) topic, like:
>>
>> ...
>> if (pushNotificationResponse.isAccepted()) {
>>   logger.trace("Push notification for '{}' (payload={})", deviceToken, pushNotificationResponse.getPushNotification().getPayload());
>>
>>   producer.send(jobID, "Success"); // sends to "push_messages" topic
>> } else {
>>   final String rejectReason = pushNotificationResponse.getRejectionReason();
>>   logger.trace("Push Message has been rejected with reason: {}", rejectReason);
>>
>>   producer.send(jobID, "Rejected"); // sends "push_messages" topic
>> ...
>> }
>>
>> Now, this sends all to one topic, and we could be using, somewhere, Kafka
>> Stream API, to perform some processing of the source, and calculate some
>> stats on that, like:
>>
>> KStreamBuilder builder = new KStreamBuilder();
>>
>> // read from the topic that contains all messages, for all jobs
>> final KStream<String, String> source = builder.stream("push_messages");
>>
>>
>> // some simple processing, and grouping by key, applying a predicate and send to three "analytic" topic:
>>
>> final KTable<String, Long> successCountsPerJob = source.filter((key, value) -> value.equals("Success"))
>>   .groupByKey()
>>   .count("successMessagesPerJob");
>> successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");
>>
>> final KTable<String, Long> failCountsPerJob = source.filter((key, value) -> value.equals("Rejected"))
>>   .groupByKey()
>>   .count("failedMessagesPerJob");
>> failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");
>>
>> source.groupByKey()
>>   count("totalMessagesPerJob")
>>     .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");
>>
>>
>> The above performs some functional processing of the single source of
>> truth, based on different assumptions.
>>
>> If one would have a simple consumer on each of these three "analytic"
>> topics, a simple logging output would be:
>>
>> 2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX
>> 2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX
>> 2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX
>>
>>
>> since for the GSoC we do have two students, working on Kafka and HBase
>> improvements for UPS, I wanted to share this quick prototype, as food for
>> thoughts.
>>
>> Of course, each of these 'filtered' consumers could than eventually store
>> the result somewhere else.
>>
>> With this approach, Kafka would be come the hub (or data pipeline) for
>> our metrics, with stream processing and different consumers to deal with
>> the results of interest
>>
>> Any comments or other thoughts?
>>
>> -Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/5e8acb5b/attachment-0001.html 

From scm.blanc at gmail.com  Tue May 16 11:31:58 2017
From: scm.blanc at gmail.com (Sebastien Blanc)
Date: Tue, 16 May 2017 17:31:58 +0200
Subject: [aerogear-dev] UPS 1.2.0-beta.1 release
In-Reply-To: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
References: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
Message-ID: <CAD_dpu01OapbYTgAhd1B6KuXKXPEZc7qbdgX9YhmtrMmWwNT7Q@mail.gmail.com>

Congrats !

On Tue, May 16, 2017 at 10:48 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> after a long time, we are running a new release of the master branch:
> 1.2.0-beta.1
>
> Most important fixes were around memory leaks and improving poor APNs
> connection handling.
> Also, internally we are now connecting against the HTTP/2 endpoints from
> APNs, as THE hightligh of this stability release, hence also moving to
> 'beta'
>
> Details can be found here:
> https://issues.jboss.org/secure/ReleaseNote.jspa?
> projectId=12313724&version=12334702
>
>
> the staging repository is located here:
> https://repository.jboss.org/nexus/content/repositories/
> jboss_releases_staging_profile-11183/
>
> Once the release is out, I will update our docker images
>
> Cheers!
> Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/7c006266/attachment.html 

From mm at napp.dk  Tue May 16 12:50:33 2017
From: mm at napp.dk (=?utf-8?B?TWFkcyBNw7hsbGVy?=)
Date: Tue, 16 May 2017 16:50:33 +0000
Subject: [aerogear-dev] Notification Delivery metrics and processing
 with Kafka
In-Reply-To: <CAAg5f2TuPHW31ZGgyKr7epWXq5o6hbQ9eZOhujKNNPPp_Po5kw@mail.gmail.com>
References: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
	<CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>
	<CAAg5f2TuPHW31ZGgyKr7epWXq5o6hbQ9eZOhujKNNPPp_Po5kw@mail.gmail.com>
Message-ID: <C16ECFA1-61EB-4BED-82C1-8B802C336A44@napp.dk>

Such great news.

It would be fantastic if failing APN connection or similar would fire off a webhook. So its possible for integrated systems can be notified.



BEST REGARDS
__________________
MADS M?LLER
CTO, PARTNER

Napp A/S
T: +45 42 42 80 60
M: +45 20 28 20 26
E: mm at napp.dk<mailto:mm at napp.dk>
W: https://napp.dk<https://napp.dk/>
__________________





From: <aerogear-dev-bounces at lists.jboss.org> on behalf of Matthias Wessendorf <matzew at apache.org>
Reply-To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
Date: Tuesday, 16 May 2017 at 16.50
To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
Subject: Re: [aerogear-dev] Notification Delivery metrics and processing with Kafka

Oh, this is far from being done :-)

I just did a little POC, and since we also have two GSoC students, we have some time to define the behavior, including UI, here on the commiunity :)

On Tue, May 16, 2017 at 3:37 PM, Jose Miguel Gallas Olmedo <jgallaso at redhat.com<mailto:jgallaso at redhat.com>> wrote:
Great news!!

Will this information be displayed in the UI? As a tooltip or when extending the row in "activity log"s table.

On 16 May 2017 at 13:58, Matthias Wessendorf <matzew at apache.org<mailto:matzew at apache.org>> wrote:

Hi,

with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get a way more finegrain knowledge if Apple did accept (for further processing) or reject a messages, on a per device_token level!

For instance, if we have a push with 5000 targeted devices, we are now able to say that 5 tokens, for instances failed, but APNs was happy to accept push request for the other 4995 devices (Note: this does NOT mean they actually arrive at the device, just that apple accepted them for further processing).

Now, this, for APNs, gives us much more flexiblity handling our metrics!

In our code, here, we do read each token request from APNs in here: https://github.com/aerogear/aerogear-unifiedpush-server/blob/20831d96196663349c96da6b5fe11aef65cacf59/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/apns/PushyApnsSender.java#L130-L147

So here, we could simply send the result, on a per token base, to a (Kafka) topic, like:

...

if (pushNotificationResponse.isAccepted()) {

  logger.trace("Push notification for '{}' (payload={})", deviceToken, pushNotificationResponse.getPushNotification().getPayload());



  producer.send(jobID, "Success"); // sends to "push_messages" topic

} else {

  final String rejectReason = pushNotificationResponse.getRejectionReason();

  logger.trace("Push Message has been rejected with reason: {}", rejectReason);



  producer.send(jobID, "Rejected"); // sends "push_messages" topic

...

}

Now, this sends all to one topic, and we could be using, somewhere, Kafka Stream API, to perform some processing of the source, and calculate some stats on that, like:

KStreamBuilder builder = new KStreamBuilder();



// read from the topic that contains all messages, for all jobs

final KStream<String, String> source = builder.stream("push_messages");





// some simple processing, and grouping by key, applying a predicate and send to three "analytic" topic:



final KTable<String, Long> successCountsPerJob = source.filter((key, value) -> value.equals("Success"))

  .groupByKey()

  .count("successMessagesPerJob");

successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");



final KTable<String, Long> failCountsPerJob = source.filter((key, value) -> value.equals("Rejected"))

  .groupByKey()

  .count("failedMessagesPerJob");

failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");



source.groupByKey()

  count("totalMessagesPerJob")

    .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");



The above performs some functional processing of the single source of truth, based on different assumptions.

If one would have a simple consumer on each of these three "analytic" topics, a simple logging output would be:

2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX

2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX

2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX



since for the GSoC we do have two students, working on Kafka and HBase improvements for UPS, I wanted to share this quick prototype, as food for thoughts.

Of course, each of these 'filtered' consumers could than eventually store the result somewhere else.

With this approach, Kafka would be come the hub (or data pipeline) for our metrics, with stream processing and different consumers to deal with the results of interest

Any comments or other thoughts?

-Matthias

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633<http://redhatemailsignature-marketing.itos.redhat.com/>
[https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png]<https://red.ht/sig>


_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/636af165/attachment-0001.html 

From idel.pivnitskiy at gmail.com  Tue May 16 14:00:35 2017
From: idel.pivnitskiy at gmail.com (Idel Pivnitskiy)
Date: Tue, 16 May 2017 11:00:35 -0700
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CABoO8LexrphgqCyV6oW18W0TMzeqi5+7zSH2LU4euwDdy861Ow@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
	<CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>
	<CABoO8Leen1Tsd0pC8X4_4ORK+h44sYMePprmDELd+jDvVn6kSg@mail.gmail.com>
	<C075CF0E-76FB-4E34-AED4-E2F8E1A1B67A@gmail.com>
	<CABoO8LexrphgqCyV6oW18W0TMzeqi5+7zSH2LU4euwDdy861Ow@mail.gmail.com>
Message-ID: <CAN+BUJpsNH9jVN+6kU+RuK5g-+WTNo9k8mFZsVszLCzb9pinzA@mail.gmail.com>

Hi Dimitra and Polina,

My congratulations to you! I think you have a very interesting opportunity
to work on the same project/idea not only in the community but like a small
team within the community. Work in a team is always better than one person
project :)

I also worked with AeroGear during the last 2 years of GSoC. My work was
focussed on WebPush protocol, which delivers push notification messages to
the browsers.

Have a great summer! Work hard - play hard :)

Best,
Idel

On Tue, May 16, 2017 at 5:22 AM, Ali Ok <aliok at redhat.com> wrote:

> Hi,
>
> My mentor was Mr. Matzew, similar to you both :)
> I was doing the project within Apache Software Foundation. I mostly
> experimented with HTML5 (which was a new thing back then) and created a JSF
> component library under Apache Myfaces.
> I became an Apache committer when the project was finished.
>
> It was fun!
>
> Cheers,
> Ali
>
> On Thu, May 11, 2017 at 11:55 PM, Dimitra <dimitrazuccarelli at gmail.com>
> wrote:
>
>> Hi Ali thanks so much!
>>
>> It's such an exciting opportunity and I'm really grateful to be a part of
>> it.
>>
>> With who (whom?) did you do your project and what was it on?
>>
>> On 11 May 2017, at 19:17, Ali Ok [via aerogear-dev] <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=12964&i=0>> wrote:
>>
>> Hi, Polina and Dimitra,
>>
>> Welcome onboard!
>>
>> I was a GSoC student in 2010 and I must tell you it is a great
>> opportunity to work with the best open source communities.
>> I am sure you will both graduate from this program successfully.
>>
>> Cheers,
>> Ali
>>
>>
>> On Thu, May 11, 2017 at 12:56 PM, Matthias Wessendorf <[hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=12962&i=0>> wrote:
>>
>>> Hi, Polina and Dimitra,
>>>
>>> thanks for the nice introduction. The first weeks for Google Summer of
>>> Code are usually about community bonding: Get to know your community, chat
>>> w/ people on IRC, check out the code base of the UPS, try examples, ask
>>> quesions on mail or on IRC.
>>>
>>> It's perhaps also a good idea to get a bit of sense of Apache Kafka,
>>> especially for stream processing.
>>>
>>> Here is a good intro on Kafka, and Kafka-Streams, and why Spark/Flink
>>> etc are not always needed ;-)
>>> https://balamaci.ro/kafka-streams-for-stream-processing/
>>>
>>> I hope you will enjoy the work over the summer! :-)
>>> Cheers,
>>> Matthias
>>>
>>>
>>>
>>> On Wed, May 10, 2017 at 7:23 PM, Dimitra Zuccarelli <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=12962&i=1>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I'm Dimitra, 21 years old from South Africa/Italy. Im currently
>>>> studying Applied Computing in Waterford, Ireland. I love programming and
>>>> similarly to Polina I'm most interested in algorithms, big data and trend
>>>> analysis.
>>>>
>>>> I can't wait to start work on this project and I'm looking forward to
>>>> getting more involved in the community!
>>>>
>>>> On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=12962&i=2>> wrote:
>>>>
>>>>> Hello AeroGear community,
>>>>>
>>>>> as the AeroGear project lead, I am thrilled to announce that this year
>>>>> we do have two students working on the AeroGear UnifiedPush server, during
>>>>> the Google Summer of Code Projects.
>>>>>
>>>>> Both students applied to the "Apache Kafka and Apache HBase"
>>>>> improvements project, and did deliver a great paper and detailed
>>>>> implementation plan.
>>>>>
>>>>> Over the summer Dimitra and Polina will work with us, in the open, in
>>>>> the community on this project.
>>>>>
>>>>> The main access point for our community is listed here. Most of us do
>>>>> hang around on IRC, and of course, if there are questions, please send
>>>>> mails to our mailing list.
>>>>>
>>>>> Details:
>>>>> https://aerogear.org/community/
>>>>>
>>>>>
>>>>> Dimitra, and Polina, I'd like to ask you to introduce yourself here on
>>>>> this mailing list (remember to subscribe for it), so that the larger
>>>>> AeroGear community gets to know you better!
>>>>>
>>>>> Cheers,
>>>>> Matthias
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=3>
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=4>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>>
>> ALI OK
>>
>> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=5>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Googl
>> e-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12962.html
>> To start a new topic under aerogear-dev, email [hidden email]
>> <http:///user/SendEmail.jtp?type=node&node=12964&i=1>
>> To unsubscribe from aerogear-dev, click here.
>> NAML
>> <http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>>
>> ------------------------------
>> View this message in context: Re: [aerogear-dev] Google summer of code:
>> WELCOME Dimitra and Polina
>> <http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12964.html>
>> Sent from the aerogear-dev mailing list archive
>> <http://aerogear-dev.1069024.n5.nabble.com/> at Nabble.com.
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> ALI OK
>
> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
>
> Red Hat
>
> <https://www.redhat.com/>
> <https://red.ht/sig>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/0d42aba2/attachment.html 

From matzew at apache.org  Tue May 16 14:04:40 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 16 May 2017 20:04:40 +0200
Subject: [aerogear-dev] Notification Delivery metrics and processing
	with Kafka
In-Reply-To: <C16ECFA1-61EB-4BED-82C1-8B802C336A44@napp.dk>
References: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
	<CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>
	<CAAg5f2TuPHW31ZGgyKr7epWXq5o6hbQ9eZOhujKNNPPp_Po5kw@mail.gmail.com>
	<C16ECFA1-61EB-4BED-82C1-8B802C336A44@napp.dk>
Message-ID: <CAAg5f2Rr=P-uBzZqm4hDCnW1meaipqMQbmxhCDt2pUN5L9d7EA@mail.gmail.com>

right!

in theory, you can also simply register a custom kafka consumer to those
topics and apply some custom logic, e.g. to ping other systems

On Tue, May 16, 2017 at 6:50 PM, Mads M?ller <mm at napp.dk> wrote:

> Such great news.
>
>
>
> It would be fantastic if failing APN connection or similar would fire off
> a webhook. So its possible for integrated systems can be notified.
>
>
>
>
>
>
>
> BEST REGARDS
>
> *__________________*
>
> *MADS M?LLER*
>
> CTO, PARTNER
>
>
>
> Napp A/S
>
> T: +45 42 42 80 60 <+45%2042%2042%2080%2060>
>
> M: +45 20 28 20 26 <+45%2020%2028%2020%2026>
>
> E: mm at napp.dk
>
> W: https://napp.dk
>
> *__________________*
>
>
>
>
>
>
>
>
>
>
>
> *From: *<aerogear-dev-bounces at lists.jboss.org> on behalf of Matthias
> Wessendorf <matzew at apache.org>
> *Reply-To: *AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
> *Date: *Tuesday, 16 May 2017 at 16.50
> *To: *AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
> *Subject: *Re: [aerogear-dev] Notification Delivery metrics and
> processing with Kafka
>
>
>
> Oh, this is far from being done :-)
>
>
>
> I just did a little POC, and since we also have two GSoC students, we have
> some time to define the behavior, including UI, here on the commiunity :)
>
>
>
> On Tue, May 16, 2017 at 3:37 PM, Jose Miguel Gallas Olmedo <
> jgallaso at redhat.com> wrote:
>
> Great news!!
>
>
>
> Will this information be displayed in the UI? As a tooltip or when
> extending the row in "activity log"s table.
>
>
>
> On 16 May 2017 at 13:58, Matthias Wessendorf <matzew at apache.org> wrote:
>
> Hi,
>
> with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get
> a way more finegrain knowledge if Apple did accept (for further processing)
> or reject a messages, on a per device_token level!
>
> For instance, if we have a push with 5000 targeted devices, we are now
> able to say that 5 tokens, for instances failed, but APNs was happy to
> accept push request for the other 4995 devices (Note: this does NOT mean
> they actually arrive at the device, just that apple accepted them for
> further processing).
>
> Now, this, for APNs, gives us much more flexiblity handling our metrics!
>
> In our code, here, we do read *each* token request from APNs in here:
> https://github.com/aerogear/aerogear-unifiedpush-server/blob/
> 20831d96196663349c96da6b5fe11aef65cacf59/push/sender/src/
> main/java/org/jboss/aerogear/unifiedpush/message/sender/
> apns/PushyApnsSender.java#L130-L147
>
> So here, we could simply send the result, on a per token base, to a
> (Kafka) topic, like:
>
> ...
>
> if (pushNotificationResponse.isAccepted()) {
>
>   logger.trace("Push notification for '{}' (payload={})", deviceToken, pushNotificationResponse.getPushNotification().getPayload());
>
>
>
>   producer.send(jobID, "Success"); // sends to "push_messages" topic
>
> } else {
>
>   final String rejectReason = pushNotificationResponse.getRejectionReason();
>
>   logger.trace("Push Message has been rejected with reason: {}", rejectReason);
>
>
>
>   producer.send(jobID, "Rejected"); // sends "push_messages" topic
>
> ...
>
> }
>
> Now, this sends all to one topic, and we could be using, somewhere, Kafka
> Stream API, to perform some processing of the source, and calculate some
> stats on that, like:
>
> KStreamBuilder builder = new KStreamBuilder();
>
>
>
> // read from the topic that contains all messages, for all jobs
>
> final KStream<String, String> source = builder.stream("push_messages");
>
>
>
>
>
> // some simple processing, and grouping by key, applying a predicate and send to three "analytic" topic:
>
>
>
> final KTable<String, Long> successCountsPerJob = source.filter((key, value) -> value.equals("Success"))
>
>   .groupByKey()
>
>   .count("successMessagesPerJob");
>
> successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");
>
>
>
> final KTable<String, Long> failCountsPerJob = source.filter((key, value) -> value.equals("Rejected"))
>
>   .groupByKey()
>
>   .count("failedMessagesPerJob");
>
> failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");
>
>
>
> source.groupByKey()
>
>   count("totalMessagesPerJob")
>
>     .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");
>
>
>
> The above performs some functional processing of the single source of
> truth, based on different assumptions.
>
> If one would have a simple consumer on each of these three "analytic"
> topics, a simple logging output would be:
>
> 2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX
>
> 2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX
>
> 2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX
>
>
>
> since for the GSoC we do have two students, working on Kafka and HBase
> improvements for UPS, I wanted to share this quick prototype, as food for
> thoughts.
>
> Of course, each of these 'filtered' consumers could than eventually store
> the result somewhere else.
>
> With this approach, Kafka would be come the hub (or data pipeline) for our
> metrics, with stream processing and different consumers to deal with the
> results of interest
>
> Any comments or other thoughts?
>
> -Matthias
>
>
>
> --
>
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
>
>
> --
>
> *JOSE MIGUEL GALLAS OLMEDO*
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
>
> <https://red.ht/sig>
>
>
> _______________________________________________
> 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/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170516/a9a6ab58/attachment-0001.html 

From mm at napp.dk  Wed May 17 01:27:08 2017
From: mm at napp.dk (=?iso-8859-1?Q?Mads_M=F8ller?=)
Date: Wed, 17 May 2017 05:27:08 +0000
Subject: [aerogear-dev] Notification Delivery metrics and
 processing	with Kafka
In-Reply-To: <CAAg5f2Rr=P-uBzZqm4hDCnW1meaipqMQbmxhCDt2pUN5L9d7EA@mail.gmail.com>
References: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
	<CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>
	<CAAg5f2TuPHW31ZGgyKr7epWXq5o6hbQ9eZOhujKNNPPp_Po5kw@mail.gmail.com>
	<C16ECFA1-61EB-4BED-82C1-8B802C336A44@napp.dk>,
	<CAAg5f2Rr=P-uBzZqm4hDCnW1meaipqMQbmxhCDt2pUN5L9d7EA@mail.gmail.com>
Message-ID: <5E952F6F-43A1-422F-A40A-F58D91FBA805@napp.dk>

Are there Any guide/turorial on setting this up?


MED VENLIG HILSEN / BEST REGARDS
__________________
MADS M?LLER
CTO, PARTNER

Napp A/S
T: 42 42 80 60
M: 20 28 20 26
E: mm at napp.dk<mailto:mm at napp.dk>
W: www.napp.dk<http://www.napp.dk>
__________________

On 16 May 2017, at 21.46, Matthias Wessendorf <matzew at apache.org<mailto:matzew at apache.org>> wrote:

right!

in theory, you can also simply register a custom kafka consumer to those topics and apply some custom logic, e.g. to ping other systems

On Tue, May 16, 2017 at 6:50 PM, Mads M?ller <mm at napp.dk<mailto:mm at napp.dk>> wrote:
Such great news.

It would be fantastic if failing APN connection or similar would fire off a webhook. So its possible for integrated systems can be notified.



BEST REGARDS
__________________
MADS M?LLER
CTO, PARTNER

Napp A/S
T: +45 42 42 80 60<tel:+45%2042%2042%2080%2060>
M: +45 20 28 20 26<tel:+45%2020%2028%2020%2026>
E: mm at napp.dk<mailto:mm at napp.dk>
W: https://napp.dk<https://napp.dk/>
__________________





From: <aerogear-dev-bounces at lists.jboss.org<mailto:aerogear-dev-bounces at lists.jboss.org>> on behalf of Matthias Wessendorf <matzew at apache.org<mailto:matzew at apache.org>>
Reply-To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>>
Date: Tuesday, 16 May 2017 at 16.50
To: AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>>
Subject: Re: [aerogear-dev] Notification Delivery metrics and processing with Kafka

Oh, this is far from being done :-)

I just did a little POC, and since we also have two GSoC students, we have some time to define the behavior, including UI, here on the commiunity :)

On Tue, May 16, 2017 at 3:37 PM, Jose Miguel Gallas Olmedo <jgallaso at redhat.com<mailto:jgallaso at redhat.com>> wrote:
Great news!!

Will this information be displayed in the UI? As a tooltip or when extending the row in "activity log"s table.

On 16 May 2017 at 13:58, Matthias Wessendorf <matzew at apache.org<mailto:matzew at apache.org>> wrote:

Hi,

with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get a way more finegrain knowledge if Apple did accept (for further processing) or reject a messages, on a per device_token level!

For instance, if we have a push with 5000 targeted devices, we are now able to say that 5 tokens, for instances failed, but APNs was happy to accept push request for the other 4995 devices (Note: this does NOT mean they actually arrive at the device, just that apple accepted them for further processing).

Now, this, for APNs, gives us much more flexiblity handling our metrics!

In our code, here, we do read each token request from APNs in here: https://github.com/aerogear/aerogear-unifiedpush-server/blob/20831d96196663349c96da6b5fe11aef65cacf59/push/sender/src/main/java/org/jboss/aerogear/unifiedpush/message/sender/apns/PushyApnsSender.java#L130-L147

So here, we could simply send the result, on a per token base, to a (Kafka) topic, like:

...

if (pushNotificationResponse.isAccepted()) {

  logger.trace("Push notification for '{}' (payload={})", deviceToken, pushNotificationResponse.getPushNotification().getPayload());



  producer.send(jobID, "Success"); // sends to "push_messages" topic

} else {

  final String rejectReason = pushNotificationResponse.getRejectionReason();

  logger.trace("Push Message has been rejected with reason: {}", rejectReason);



  producer.send(jobID, "Rejected"); // sends "push_messages" topic

...

}

Now, this sends all to one topic, and we could be using, somewhere, Kafka Stream API, to perform some processing of the source, and calculate some stats on that, like:

KStreamBuilder builder = new KStreamBuilder();



// read from the topic that contains all messages, for all jobs

final KStream<String, String> source = builder.stream("push_messages");





// some simple processing, and grouping by key, applying a predicate and send to three "analytic" topic:



final KTable<String, Long> successCountsPerJob = source.filter((key, value) -> value.equals("Success"))

  .groupByKey()

  .count("successMessagesPerJob");

successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");



final KTable<String, Long> failCountsPerJob = source.filter((key, value) -> value.equals("Rejected"))

  .groupByKey()

  .count("failedMessagesPerJob");

failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");



source.groupByKey()

  count("totalMessagesPerJob")

    .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");



The above performs some functional processing of the single source of truth, based on different assumptions.

If one would have a simple consumer on each of these three "analytic" topics, a simple logging output would be:

2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX

2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX

2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX



since for the GSoC we do have two students, working on Kafka and HBase improvements for UPS, I wanted to share this quick prototype, as food for thoughts.

Of course, each of these 'filtered' consumers could than eventually store the result somewhere else.

With this approach, Kafka would be come the hub (or data pipeline) for our metrics, with stream processing and different consumers to deal with the results of interest

Any comments or other thoughts?

-Matthias

--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633<http://redhatemailsignature-marketing.itos.redhat.com/>
[https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png]<https://red.ht/sig>


_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org<mailto:aerogear-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170517/6c426ea9/attachment-0001.html 

From dimitrazuccarelli at gmail.com  Wed May 17 03:31:06 2017
From: dimitrazuccarelli at gmail.com (Dimitra Zuccarelli)
Date: Wed, 17 May 2017 08:31:06 +0100
Subject: [aerogear-dev] UPS 1.2.0-beta.1 release
In-Reply-To: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
References: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
Message-ID: <CAFia+62Equ-a2JL3k7ciDe8VjbsnM8vn2msc0BaxgWcq8KGN0g@mail.gmail.com>

Great news!

On Tue, May 16, 2017 at 9:48 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> after a long time, we are running a new release of the master branch:
> 1.2.0-beta.1
>
> Most important fixes were around memory leaks and improving poor APNs
> connection handling.
> Also, internally we are now connecting against the HTTP/2 endpoints from
> APNs, as THE hightligh of this stability release, hence also moving to
> 'beta'
>
> Details can be found here:
> https://issues.jboss.org/secure/ReleaseNote.jspa?
> projectId=12313724&version=12334702
>
>
> the staging repository is located here:
> https://repository.jboss.org/nexus/content/repositories/
> jboss_releases_staging_profile-11183/
>
> Once the release is out, I will update our docker images
>
> Cheers!
> Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170517/ee82b2a3/attachment.html 

From matzew at apache.org  Wed May 17 05:58:19 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 17 May 2017 11:58:19 +0200
Subject: [aerogear-dev] Notification Delivery metrics and processing
	with Kafka
In-Reply-To: <5E952F6F-43A1-422F-A40A-F58D91FBA805@napp.dk>
References: <CAAg5f2TE6uxn010J0iWeyQkrBzT=itM0Ezjn+O5+6FBPgh1q4w@mail.gmail.com>
	<CAGsbZmFsk4+MtoQa4ycU68qy8GceDyNxWJftJZbG_azV8xVqAw@mail.gmail.com>
	<CAAg5f2TuPHW31ZGgyKr7epWXq5o6hbQ9eZOhujKNNPPp_Po5kw@mail.gmail.com>
	<C16ECFA1-61EB-4BED-82C1-8B802C336A44@napp.dk>
	<CAAg5f2Rr=P-uBzZqm4hDCnW1meaipqMQbmxhCDt2pUN5L9d7EA@mail.gmail.com>
	<5E952F6F-43A1-422F-A40A-F58D91FBA805@napp.dk>
Message-ID: <CAAg5f2S9bL9Dmkns-WNW8WnAKNZAoOUJJLa2Bom-466V1hFzXA@mail.gmail.com>

we have nothing yet - this is just getting started.

Over the summer we have two students, as part of the Google Summer of Code,
working on this.

I just did a POC to evaluate the idea ;-)

On Wed, May 17, 2017 at 7:27 AM, Mads M?ller <mm at napp.dk> wrote:

> Are there Any guide/turorial on setting this up?
>
>
> MED VENLIG HILSEN / BEST REGARDS
> __________________
> MADS M?LLER
> CTO, PARTNER
>
> Napp A/S
> T: 42 42 80 60
> M: 20 28 20 26
> E: mm at napp.dk
> W: www.napp.dk
> __________________
>
> On 16 May 2017, at 21.46, Matthias Wessendorf <matzew at apache.org> wrote:
>
> right!
>
> in theory, you can also simply register a custom kafka consumer to those
> topics and apply some custom logic, e.g. to ping other systems
>
> On Tue, May 16, 2017 at 6:50 PM, Mads M?ller <mm at napp.dk> wrote:
>
>> Such great news.
>>
>>
>>
>> It would be fantastic if failing APN connection or similar would fire off
>> a webhook. So its possible for integrated systems can be notified.
>>
>>
>>
>>
>>
>>
>>
>> BEST REGARDS
>>
>> *__________________*
>>
>> *MADS M?LLER*
>>
>> CTO, PARTNER
>>
>>
>>
>> Napp A/S
>>
>> T: +45 42 42 80 60 <+45%2042%2042%2080%2060>
>>
>> M: +45 20 28 20 26 <+45%2020%2028%2020%2026>
>>
>> E: mm at napp.dk
>>
>> W: https://napp.dk
>>
>> *__________________*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From: *<aerogear-dev-bounces at lists.jboss.org> on behalf of Matthias
>> Wessendorf <matzew at apache.org>
>> *Reply-To: *AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org
>> >
>> *Date: *Tuesday, 16 May 2017 at 16.50
>> *To: *AeroGear Developer Mailing List <aerogear-dev at lists.jboss.org>
>> *Subject: *Re: [aerogear-dev] Notification Delivery metrics and
>> processing with Kafka
>>
>>
>>
>> Oh, this is far from being done :-)
>>
>>
>>
>> I just did a little POC, and since we also have two GSoC students, we
>> have some time to define the behavior, including UI, here on the commiunity
>> :)
>>
>>
>>
>> On Tue, May 16, 2017 at 3:37 PM, Jose Miguel Gallas Olmedo <
>> jgallaso at redhat.com> wrote:
>>
>> Great news!!
>>
>>
>>
>> Will this information be displayed in the UI? As a tooltip or when
>> extending the row in "activity log"s table.
>>
>>
>>
>> On 16 May 2017 at 13:58, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>> Hi,
>>
>> with the new APNs HTTP/2 APIs, and our usage of Pushy, we are able to get
>> a way more finegrain knowledge if Apple did accept (for further processing)
>> or reject a messages, on a per device_token level!
>>
>> For instance, if we have a push with 5000 targeted devices, we are now
>> able to say that 5 tokens, for instances failed, but APNs was happy to
>> accept push request for the other 4995 devices (Note: this does NOT mean
>> they actually arrive at the device, just that apple accepted them for
>> further processing).
>>
>> Now, this, for APNs, gives us much more flexiblity handling our metrics!
>>
>> In our code, here, we do read *each* token request from APNs in here:
>> https://github.com/aerogear/aerogear-unifiedpush-serve
>> r/blob/20831d96196663349c96da6b5fe11aef65cacf59/push/sender/
>> src/main/java/org/jboss/aerogear/unifiedpush/message/
>> sender/apns/PushyApnsSender.java#L130-L147
>>
>> So here, we could simply send the result, on a per token base, to a
>> (Kafka) topic, like:
>>
>> ...
>>
>> if (pushNotificationResponse.isAccepted()) {
>>
>>   logger.trace("Push notification for '{}' (payload={})", deviceToken, pushNotificationResponse.getPushNotification().getPayload());
>>
>>
>>
>>   producer.send(jobID, "Success"); // sends to "push_messages" topic
>>
>> } else {
>>
>>   final String rejectReason = pushNotificationResponse.getRejectionReason();
>>
>>   logger.trace("Push Message has been rejected with reason: {}", rejectReason);
>>
>>
>>
>>   producer.send(jobID, "Rejected"); // sends "push_messages" topic
>>
>> ...
>>
>> }
>>
>> Now, this sends all to one topic, and we could be using, somewhere, Kafka
>> Stream API, to perform some processing of the source, and calculate some
>> stats on that, like:
>>
>> KStreamBuilder builder = new KStreamBuilder();
>>
>>
>>
>> // read from the topic that contains all messages, for all jobs
>>
>> final KStream<String, String> source = builder.stream("push_messages");
>>
>>
>>
>>
>>
>> // some simple processing, and grouping by key, applying a predicate and send to three "analytic" topic:
>>
>>
>>
>> final KTable<String, Long> successCountsPerJob = source.filter((key, value) -> value.equals("Success"))
>>
>>   .groupByKey()
>>
>>   .count("successMessagesPerJob");
>>
>> successCountsPerJob.to(Serdes.String(), Serdes.Long(), "successMessagesPerJob");
>>
>>
>>
>> final KTable<String, Long> failCountsPerJob = source.filter((key, value) -> value.equals("Rejected"))
>>
>>   .groupByKey()
>>
>>   .count("failedMessagesPerJob");
>>
>> failCountsPerJob.to(Serdes.String(), Serdes.Long(), "failedMessagesPerJob");
>>
>>
>>
>> source.groupByKey()
>>
>>   count("totalMessagesPerJob")
>>
>>     .to(Serdes.String(), Serdes.Long(), "totalMessagesPerJob");
>>
>>
>>
>> The above performs some functional processing of the single source of
>> truth, based on different assumptions.
>>
>> If one would have a simple consumer on each of these three "analytic"
>> topics, a simple logging output would be:
>>
>> 2017-05-16 13:42:48,763 INFO  successMessagesPerJob: 2 - jobID: XXX
>>
>> 2017-05-16 13:42:48,764 INFO  totalMessagesPerJob: 3 - jobID: XXX
>>
>> 2017-05-16 13:42:48,764 INFO  failedMessagesPerJob: 1 - jobID: XXX
>>
>>
>>
>> since for the GSoC we do have two students, working on Kafka and HBase
>> improvements for UPS, I wanted to share this quick prototype, as food for
>> thoughts.
>>
>> Of course, each of these 'filtered' consumers could than eventually store
>> the result somewhere else.
>>
>> With this approach, Kafka would be come the hub (or data pipeline) for
>> our metrics, with stream processing and different consumers to deal with
>> the results of interest
>>
>> Any comments or other thoughts?
>>
>> -Matthias
>>
>>
>>
>> --
>>
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>>
>> --
>>
>> *JOSE MIGUEL GALLAS OLMEDO*
>>
>> ASSOCIATE QE, mobile
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>>
>> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>>
>>
>> <https://red.ht/sig>
>>
>>
>> _______________________________________________
>> 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/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> 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/
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170517/60bff664/attachment-0001.html 

From matzew at apache.org  Wed May 17 07:00:59 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 17 May 2017 13:00:59 +0200
Subject: [aerogear-dev] UPS 1.2.0-beta.1 release
In-Reply-To: <CAFia+62Equ-a2JL3k7ciDe8VjbsnM8vn2msc0BaxgWcq8KGN0g@mail.gmail.com>
References: <CAAg5f2QqMYPsHcygPcPfUYP4d-fYFVV72ZnRmra3n+bxA6QsXw@mail.gmail.com>
	<CAFia+62Equ-a2JL3k7ciDe8VjbsnM8vn2msc0BaxgWcq8KGN0g@mail.gmail.com>
Message-ID: <CAAg5f2QVWX6+1Rf8BNnxwQbfHwFiJg64PPc=2Kid2pNco2zJXw@mail.gmail.com>

Thanks,

button clicked, other updates (e.g. Docker) to follow

On Wed, May 17, 2017 at 9:31 AM, Dimitra Zuccarelli <
dimitrazuccarelli at gmail.com> wrote:

> Great news!
>
> On Tue, May 16, 2017 at 9:48 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> after a long time, we are running a new release of the master branch:
>> 1.2.0-beta.1
>>
>> Most important fixes were around memory leaks and improving poor APNs
>> connection handling.
>> Also, internally we are now connecting against the HTTP/2 endpoints from
>> APNs, as THE hightligh of this stability release, hence also moving to
>> 'beta'
>>
>> Details can be found here:
>> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=
>> 12313724&version=12334702
>>
>>
>> the staging repository is located here:
>> https://repository.jboss.org/nexus/content/repositories/jbos
>> s_releases_staging_profile-11183/
>>
>> Once the release is out, I will update our docker images
>>
>> Cheers!
>> Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170517/4a5c4a46/attachment.html 

From matzew at apache.org  Tue May 23 05:47:03 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 23 May 2017 11:47:03 +0200
Subject: [aerogear-dev] Openshift for UPS
Message-ID: <CAAg5f2R=urRLKA317zL2Tdd-aBt7GzjBkfCmcEaGK5fySyLgXg@mail.gmail.com>

Hi Dimitra,
Hi, Summers,

since we now have Openshift template for UPS, I think this one is "done",
right?

https://issues.jboss.org/browse/AGPUSH-1556

Or is there more ? :)

Thanks



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170523/7ef27524/attachment.html 

From supittma at redhat.com  Tue May 23 07:22:14 2017
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 23 May 2017 07:22:14 -0400
Subject: [aerogear-dev] Openshift for UPS
In-Reply-To: <CAAg5f2R=urRLKA317zL2Tdd-aBt7GzjBkfCmcEaGK5fySyLgXg@mail.gmail.com>
References: <CAAg5f2R=urRLKA317zL2Tdd-aBt7GzjBkfCmcEaGK5fySyLgXg@mail.gmail.com>
Message-ID: <CAEQz2CujQW2BFPJzTyXz+C_+pD6Y=QEKSDsu3o7BXSm6TXt8NA@mail.gmail.com>

I would say so

On May 23, 2017 7:17 AM, "Matthias Wessendorf" <matzew at apache.org> wrote:

> Hi Dimitra,
> Hi, Summers,
>
> since we now have Openshift template for UPS, I think this one is "done",
> right?
>
> https://issues.jboss.org/browse/AGPUSH-1556
>
> Or is there more ? :)
>
> Thanks
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170523/5113196e/attachment.html 

From matzew at apache.org  Tue May 23 08:56:54 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 23 May 2017 14:56:54 +0200
Subject: [aerogear-dev] Openshift for UPS
In-Reply-To: <CAEQz2CujQW2BFPJzTyXz+C_+pD6Y=QEKSDsu3o7BXSm6TXt8NA@mail.gmail.com>
References: <CAAg5f2R=urRLKA317zL2Tdd-aBt7GzjBkfCmcEaGK5fySyLgXg@mail.gmail.com>
	<CAEQz2CujQW2BFPJzTyXz+C_+pD6Y=QEKSDsu3o7BXSm6TXt8NA@mail.gmail.com>
Message-ID: <CAAg5f2RHHPNi2i5vBFV7n+L3J2fPMuC_DN2KcQ-Kt53143qfpg@mail.gmail.com>

I've just marked it as closed, thanks for the reply, summers!

On Tue, May 23, 2017 at 1:22 PM, Summers Pittman <supittma at redhat.com>
wrote:

> I would say so
>
> On May 23, 2017 7:17 AM, "Matthias Wessendorf" <matzew at apache.org> wrote:
>
>> Hi Dimitra,
>> Hi, Summers,
>>
>> since we now have Openshift template for UPS, I think this one is "done",
>> right?
>>
>> https://issues.jboss.org/browse/AGPUSH-1556
>>
>> Or is there more ? :)
>>
>> Thanks
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170523/4a5babb1/attachment.html 

From dimitrazuccarelli at gmail.com  Tue May 23 11:24:12 2017
From: dimitrazuccarelli at gmail.com (Dimitra Zuccarelli)
Date: Tue, 23 May 2017 16:24:12 +0100
Subject: [aerogear-dev] Openshift UPS template
Message-ID: <CAFia+62zZ43_Zis896yxP+q1YPsO0ANnN9biXOPyD9eUk3v_Lg@mail.gmail.com>

Hi,

I've just had to wipe my computer so I'm in the process of trying to get
Openshift back up and running with the UPS template.

I can't seem to get it working because the MySQL pods consistently fail
with the error:

[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use
--explicit_defaults_for_timestamp server option (see documentation for more
details).


[ERROR] The server option 'lower_case_table_names' is configured to use
case sensitive table names but the data directory is on a case-insensitive
file system which is an unsupported combination. Please consider either
using a case sensitive file system for your data directory or switching to
a case-insensitive table name mode.


[ERROR] Aborting

I've set the env variable LOWER_CASE_TABLE_NAMES to 2 (
https://hub.docker.com/r/centos/mysql-57-centos7/) but I'm still getting
the same error.

Does anyone have any insight on how to fix this?
Thanks!

Dimitra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170523/bdfdfaa5/attachment-0001.html 

From matzew at apache.org  Wed May 24 04:30:48 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 24 May 2017 10:30:48 +0200
Subject: [aerogear-dev] Simplify the metrics for sanity
Message-ID: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>

Hi,

we do have a problem w/ our current metrics processing. It's complicated
(lot'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.

I'd like to dramatically simplify our metrics processing... to something
like:
Success -> could connect to 3rd party, to deliver tokens
Failure -> something went wrong when talking to 3rd party service.


Right now we do have metrics on push delivery:
Pending -> the submission to the 3rd party provider is in flight
Success -> we were able to connect, and could deliver *something*
Failure -> something obvious, like invalid certificate (APNs), no
connection to 3rd party possible, etc

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'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.

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).

So, for now, I'd like to dramatically simplify the code, and go with the
above Success/Failure solution.

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.

This will give us much more freedom and flexibility. Perhaps also, in the
future, we want some different stats, and something like Prometheus
/Grafana:
https://prometheus.io/docs/visualization/grafana/

A more flexible system, with independent metrics 'calculation' processing
will help us here.

Any thoughts?

-Matthias



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorfa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170524/22d4537d/attachment.html 

From matzew at apache.org  Wed May 24 08:33:10 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 24 May 2017 14:33:10 +0200
Subject: [aerogear-dev] Openshift UPS template
In-Reply-To: <CAFia+62zZ43_Zis896yxP+q1YPsO0ANnN9biXOPyD9eUk3v_Lg@mail.gmail.com>
References: <CAFia+62zZ43_Zis896yxP+q1YPsO0ANnN9biXOPyD9eUk3v_Lg@mail.gmail.com>
Message-ID: <CAAg5f2RWsyyJL4P8dSLXoB_4sPKDnEaCaadLwa8Nzp5MDzxm3w@mail.gmail.com>

does it work w/ MySQL 5.5 ?

that's what we use on our installation, and in our docker-compose files

On Tue, May 23, 2017 at 5:24 PM, Dimitra Zuccarelli <
dimitrazuccarelli at gmail.com> wrote:

> Hi,
>
> I've just had to wipe my computer so I'm in the process of trying to get
> Openshift back up and running with the UPS template.
>
> I can't seem to get it working because the MySQL pods consistently fail
> with the error:
>
> [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use
> --explicit_defaults_for_timestamp server option (see documentation for
> more details).
>
>
> [ERROR] The server option 'lower_case_table_names' is configured to use
> case sensitive table names but the data directory is on a case-insensitive
> file system which is an unsupported combination. Please consider either
> using a case sensitive file system for your data directory or switching to
> a case-insensitive table name mode.
>
>
> [ERROR] Aborting
>
> I've set the env variable LOWER_CASE_TABLE_NAMES to 2 (
> https://hub.docker.com/r/centos/mysql-57-centos7/) but I'm still getting
> the same error.
>
> Does anyone have any insight on how to fix this?
> Thanks!
>
> Dimitra
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170524/5bf93135/attachment.html 

From supittma at redhat.com  Wed May 24 08:41:28 2017
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 24 May 2017 08:41:28 -0400
Subject: [aerogear-dev] Openshift UPS template
In-Reply-To: <CAFia+62zZ43_Zis896yxP+q1YPsO0ANnN9biXOPyD9eUk3v_Lg@mail.gmail.com>
References: <CAFia+62zZ43_Zis896yxP+q1YPsO0ANnN9biXOPyD9eUk3v_Lg@mail.gmail.com>
Message-ID: <CAEQz2Cv2NYQB9xkKpFBcTygHaPAd2TkC0Vp4SqqThqzjKSH=+w@mail.gmail.com>

On Tue, May 23, 2017 at 11:24 AM, Dimitra Zuccarelli <
dimitrazuccarelli at gmail.com> wrote:

> Hi,
>
> I've just had to wipe my computer so I'm in the process of trying to get
> Openshift back up and running with the UPS template.
>
> I can't seem to get it working because the MySQL pods consistently fail
> with the error:
>
> [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use
> --explicit_defaults_for_timestamp server option (see documentation for
> more details).
>
>
> [ERROR] The server option 'lower_case_table_names' is configured to use
> case sensitive table names but the data directory is on a case-insensitive
> file system which is an unsupported combination. Please consider either
> using a case sensitive file system for your data directory or switching to
> a case-insensitive table name mode.
>
>
> [ERROR] Aborting
>
> I've set the env variable LOWER_CASE_TABLE_NAMES to 2 (
> https://hub.docker.com/r/centos/mysql-57-centos7/) but I'm still getting
> the same error.
>
> Does anyone have any insight on how to fix this?
>

I'm just curious how you got a case insensitive filesystem.

Also the env variable is "MYSQL_LOWER_CASE_TABLE_NAMES" not "
LOWER_CASE_TABLE_NAMES" That may be a problem too.



> Thanks!
>
> Dimitra
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170524/fe2f0c3c/attachment.html 

From omatskiv at redhat.com  Wed May 24 11:58:04 2017
From: omatskiv at redhat.com (Oleh Mackiv)
Date: Wed, 24 May 2017 17:58:04 +0200
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
Message-ID: <CALimhXodxZ+iJ=0-A_fyMoh+L=3cWO4Ton1jvLrUwqgtB618bQ@mail.gmail.com>

Hi Matthias,
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't
add much value.

Cheers,
Oleg

On Wed, May 24, 2017 at 10:30 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> we do have a problem w/ our current metrics processing. It's complicated
> (lot'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.
>
> I'd like to dramatically simplify our metrics processing... to something
> like:
> Success -> could connect to 3rd party, to deliver tokens
> Failure -> something went wrong when talking to 3rd party service.
>
>
> Right now we do have metrics on push delivery:
> Pending -> the submission to the 3rd party provider is in flight
> Success -> we were able to connect, and could deliver *something*
> Failure -> something obvious, like invalid certificate (APNs), no
> connection to 3rd party possible, etc
>
> 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'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.
>
> 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).
>
> So, for now, I'd like to dramatically simplify the code, and go with the
> above Success/Failure solution.
>
> 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.
>
> This will give us much more freedom and flexibility. Perhaps also, in the
> future, we want some different stats, and something like Prometheus
> /Grafana:
> https://prometheus.io/docs/visualization/grafana/
>
> A more flexible system, with independent metrics 'calculation' processing
> will help us here.
>
> Any thoughts?
>
> -Matthias
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorfa
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
omatskiv at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170524/9adf83e5/attachment-0001.html 

From lgriffin at redhat.com  Thu May 25 07:26:46 2017
From: lgriffin at redhat.com (Leigh Griffin)
Date: Thu, 25 May 2017 12:26:46 +0100
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CALimhXodxZ+iJ=0-A_fyMoh+L=3cWO4Ton1jvLrUwqgtB618bQ@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
	<CALimhXodxZ+iJ=0-A_fyMoh+L=3cWO4Ton1jvLrUwqgtB618bQ@mail.gmail.com>
Message-ID: <CAOQ+WrrSD8pe0vCHhrvZE0qv6tKe2WP4Or0mFBhUW3sGvA-OeQ@mail.gmail.com>

+1 to removing it and rethinking the value in what is presented!

It could also lead to false assumptions about end device delivery, when in
reality it's delivering it to the gateway.

On Wed, May 24, 2017 at 4:58 PM, Oleh Mackiv <omatskiv at redhat.com> wrote:

> Hi Matthias,
> 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't
> add much value.
>
> Cheers,
> Oleg
>
> On Wed, May 24, 2017 at 10:30 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> we do have a problem w/ our current metrics processing. It's complicated
>> (lot'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.
>>
>> I'd like to dramatically simplify our metrics processing... to something
>> like:
>> Success -> could connect to 3rd party, to deliver tokens
>> Failure -> something went wrong when talking to 3rd party service.
>>
>>
>> Right now we do have metrics on push delivery:
>> Pending -> the submission to the 3rd party provider is in flight
>> Success -> we were able to connect, and could deliver *something*
>> Failure -> something obvious, like invalid certificate (APNs), no
>> connection to 3rd party possible, etc
>>
>> 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'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.
>>
>> 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).
>>
>> So, for now, I'd like to dramatically simplify the code, and go with the
>> above Success/Failure solution.
>>
>> 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.
>>
>> This will give us much more freedom and flexibility. Perhaps also, in the
>> future, we want some different stats, and something like Prometheus
>> /Grafana:
>> https://prometheus.io/docs/visualization/grafana/
>>
>> A more flexible system, with independent metrics 'calculation' processing
>> will help us here.
>>
>> Any thoughts?
>>
>> -Matthias
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorfa
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Oleg Matskiv
> Associate Quality Engineer
> Red Hat Mobile Application Platform
> omatskiv at redhat.com
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland <https://www.redhat.com/>

Communications House, Cork Road

Waterford City, Ireland X91NY33

lgriffin at redhat.com    M: +353877545162     IM: lgriffin
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

@redhatway <https://twitter.com/redhatway>   @redhatinc
<https://instagram.com/redhatinc>   @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170525/1931ae96/attachment.html 

From dimitrazuccarelli at gmail.com  Thu May 25 18:34:21 2017
From: dimitrazuccarelli at gmail.com (Dimitra Zuccarelli)
Date: Thu, 25 May 2017 23:34:21 +0100
Subject: [aerogear-dev] Openshift UPS template
In-Reply-To: <CAEQz2Cv2NYQB9xkKpFBcTygHaPAd2TkC0Vp4SqqThqzjKSH=+w@mail.gmail.com>
References: <CAFia+62zZ43_Zis896yxP+q1YPsO0ANnN9biXOPyD9eUk3v_Lg@mail.gmail.com>
	<CAEQz2Cv2NYQB9xkKpFBcTygHaPAd2TkC0Vp4SqqThqzjKSH=+w@mail.gmail.com>
Message-ID: <CAFia+62G8+G5b1VAGsz26dnyzL11GWx7dUn86t=MP3cjG+f0AA@mail.gmail.com>

Thanks!

I tried with the mysql 5.5 image but the easiest way was just using the
correct env var, MYSQL_LOWER_CASE_TABLE_NAMES because I didn't have to
change too much in the template.

It's working well now, thanks for the help :)

On Wed, May 24, 2017 at 1:41 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Tue, May 23, 2017 at 11:24 AM, Dimitra Zuccarelli <
> dimitrazuccarelli at gmail.com> wrote:
>
>> Hi,
>>
>> I've just had to wipe my computer so I'm in the process of trying to get
>> Openshift back up and running with the UPS template.
>>
>> I can't seem to get it working because the MySQL pods consistently fail
>> with the error:
>>
>> [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use
>> --explicit_defaults_for_timestamp server option (see documentation for
>> more details).
>>
>>
>> [ERROR] The server option 'lower_case_table_names' is configured to use
>> case sensitive table names but the data directory is on a case-insensitive
>> file system which is an unsupported combination. Please consider either
>> using a case sensitive file system for your data directory or switching to
>> a case-insensitive table name mode.
>>
>>
>> [ERROR] Aborting
>>
>> I've set the env variable LOWER_CASE_TABLE_NAMES to 2 (
>> https://hub.docker.com/r/centos/mysql-57-centos7/) but I'm still getting
>> the same error.
>>
>> Does anyone have any insight on how to fix this?
>>
>
> I'm just curious how you got a case insensitive filesystem.
>
> Also the env variable is "MYSQL_LOWER_CASE_TABLE_NAMES" not "
> LOWER_CASE_TABLE_NAMES" That may be a problem too.
>
>
>
>> Thanks!
>>
>> Dimitra
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170525/b473188a/attachment.html 

From jgallaso at redhat.com  Fri May 26 03:48:57 2017
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Fri, 26 May 2017 09:48:57 +0200
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAOQ+WrrSD8pe0vCHhrvZE0qv6tKe2WP4Or0mFBhUW3sGvA-OeQ@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
	<CALimhXodxZ+iJ=0-A_fyMoh+L=3cWO4Ton1jvLrUwqgtB618bQ@mail.gmail.com>
	<CAOQ+WrrSD8pe0vCHhrvZE0qv6tKe2WP4Or0mFBhUW3sGvA-OeQ@mail.gmail.com>
Message-ID: <CAGsbZmEAhU5-JRHd_MGCjb3RxGEisdgKCErcf6QwZdMZJxZ5SA@mail.gmail.com>

I say,



and then rethinking what value we want to give and how to do it properly.

Just one thing, we need the "pending" state for the UI as a "loading"
state, from the moment we click the button "send notification" until one of
the two states you propose is reached.
?

On 25 May 2017 at 13:26, Leigh Griffin <lgriffin at redhat.com> wrote:

> +1 to removing it and rethinking the value in what is presented!
>
> It could also lead to false assumptions about end device delivery, when in
> reality it's delivering it to the gateway.
>
> On Wed, May 24, 2017 at 4:58 PM, Oleh Mackiv <omatskiv at redhat.com> wrote:
>
>> Hi Matthias,
>> 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't
>> add much value.
>>
>> Cheers,
>> Oleg
>>
>> On Wed, May 24, 2017 at 10:30 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> we do have a problem w/ our current metrics processing. It's complicated
>>> (lot'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.
>>>
>>> I'd like to dramatically simplify our metrics processing... to something
>>> like:
>>> Success -> could connect to 3rd party, to deliver tokens
>>> Failure -> something went wrong when talking to 3rd party service.
>>>
>>>
>>> Right now we do have metrics on push delivery:
>>> Pending -> the submission to the 3rd party provider is in flight
>>> Success -> we were able to connect, and could deliver *something*
>>> Failure -> something obvious, like invalid certificate (APNs), no
>>> connection to 3rd party possible, etc
>>>
>>> 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'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.
>>>
>>> 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).
>>>
>>> So, for now, I'd like to dramatically simplify the code, and go with the
>>> above Success/Failure solution.
>>>
>>> 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.
>>>
>>> This will give us much more freedom and flexibility. Perhaps also, in
>>> the future, we want some different stats, and something like Prometheus
>>> /Grafana:
>>> https://prometheus.io/docs/visualization/grafana/
>>>
>>> A more flexible system, with independent metrics 'calculation'
>>> processing will help us here.
>>>
>>> Any thoughts?
>>>
>>> -Matthias
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorfa
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Oleg Matskiv
>> Associate Quality Engineer
>> Red Hat Mobile Application Platform
>> omatskiv at redhat.com
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> LEIGH GRIFFIN
>
> ENGINEERING MANAGER, MOBILE
>
> Red Hat Ireland <https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford City, Ireland X91NY33
>
> lgriffin at redhat.com    M: +353877545162     IM: lgriffin
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
> @redhatway <https://twitter.com/redhatway>   @redhatinc
> <https://instagram.com/redhatinc>   @redhatsnaps
> <https://snapchat.com/add/redhatsnaps>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170526/316cf930/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kill-it.gif
Type: image/gif
Size: 158108 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170526/316cf930/attachment-0001.gif 

From matzew at apache.org  Fri May 26 07:16:00 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 26 May 2017 13:16:00 +0200
Subject: [aerogear-dev] WildFly 11
Message-ID: <CAAg5f2T=5sg5wgQHYZQwYSMR0BJeuV++cx1js2TiirZxptD5rg@mail.gmail.com>

Hi,

while WF 11.0 is not yet release, I'd like to see us getting on to WF 11 on
the master branch

http://wildfly.org/downloads/

I think that our master branch should be exclusively target the latest from
WF stable, which is 11 in the future. So getting to know what's problematic
w/ the WF 11-alpha series is a good thing.

Comments ?

-Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170526/c971f3fc/attachment.html 

From jusanche at redhat.com  Mon May 29 10:16:28 2017
From: jusanche at redhat.com (Julio Cesar Sanchez Hernandez)
Date: Mon, 29 May 2017 16:16:28 +0200
Subject: [aerogear-dev] Google summer of code: WELCOME Dimitra and Polina
In-Reply-To: <CAN+BUJpsNH9jVN+6kU+RuK5g-+WTNo9k8mFZsVszLCzb9pinzA@mail.gmail.com>
References: <CAAg5f2R94oFs5iZi0o29icMor__tUro2tCTuGA=woT3HLDGarg@mail.gmail.com>
	<CAFia+63zyAkBoN30ZaLrYS29cong_6q32d2UVyamvS_aKZxqnw@mail.gmail.com>
	<CAAg5f2QEJU93R-n3Q7O6T-psUrhEtuc9X6zHpQxtQoCnbh9Tiw@mail.gmail.com>
	<CABoO8Leen1Tsd0pC8X4_4ORK+h44sYMePprmDELd+jDvVn6kSg@mail.gmail.com>
	<C075CF0E-76FB-4E34-AED4-E2F8E1A1B67A@gmail.com>
	<CABoO8LexrphgqCyV6oW18W0TMzeqi5+7zSH2LU4euwDdy861Ow@mail.gmail.com>
	<CAN+BUJpsNH9jVN+6kU+RuK5g-+WTNo9k8mFZsVszLCzb9pinzA@mail.gmail.com>
Message-ID: <CA+-uZpvuObXdZA+=o1B63-jCjvMH+Odc+PLDYyk1j18MNXnBzg@mail.gmail.com>

Hi, Polina and Dimitra,

Welcome to the project!

Cheers.

Julio



On Tue, May 16, 2017 at 8:00 PM, Idel Pivnitskiy <idel.pivnitskiy at gmail.com>
wrote:

> Hi Dimitra and Polina,
>
> My congratulations to you! I think you have a very interesting opportunity
> to work on the same project/idea not only in the community but like a small
> team within the community. Work in a team is always better than one person
> project :)
>
> I also worked with AeroGear during the last 2 years of GSoC. My work was
> focussed on WebPush protocol, which delivers push notification messages to
> the browsers.
>
> Have a great summer! Work hard - play hard :)
>
> Best,
> Idel
>
> On Tue, May 16, 2017 at 5:22 AM, Ali Ok <aliok at redhat.com> wrote:
>
>> Hi,
>>
>> My mentor was Mr. Matzew, similar to you both :)
>> I was doing the project within Apache Software Foundation. I mostly
>> experimented with HTML5 (which was a new thing back then) and created a JSF
>> component library under Apache Myfaces.
>> I became an Apache committer when the project was finished.
>>
>> It was fun!
>>
>> Cheers,
>> Ali
>>
>> On Thu, May 11, 2017 at 11:55 PM, Dimitra <dimitrazuccarelli at gmail.com>
>> wrote:
>>
>>> Hi Ali thanks so much!
>>>
>>> It's such an exciting opportunity and I'm really grateful to be a part
>>> of it.
>>>
>>> With who (whom?) did you do your project and what was it on?
>>>
>>> On 11 May 2017, at 19:17, Ali Ok [via aerogear-dev] <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=12964&i=0>> wrote:
>>>
>>> Hi, Polina and Dimitra,
>>>
>>> Welcome onboard!
>>>
>>> I was a GSoC student in 2010 and I must tell you it is a great
>>> opportunity to work with the best open source communities.
>>> I am sure you will both graduate from this program successfully.
>>>
>>> Cheers,
>>> Ali
>>>
>>>
>>> On Thu, May 11, 2017 at 12:56 PM, Matthias Wessendorf <[hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=12962&i=0>> wrote:
>>>
>>>> Hi, Polina and Dimitra,
>>>>
>>>> thanks for the nice introduction. The first weeks for Google Summer of
>>>> Code are usually about community bonding: Get to know your community, chat
>>>> w/ people on IRC, check out the code base of the UPS, try examples, ask
>>>> quesions on mail or on IRC.
>>>>
>>>> It's perhaps also a good idea to get a bit of sense of Apache Kafka,
>>>> especially for stream processing.
>>>>
>>>> Here is a good intro on Kafka, and Kafka-Streams, and why Spark/Flink
>>>> etc are not always needed ;-)
>>>> https://balamaci.ro/kafka-streams-for-stream-processing/
>>>>
>>>> I hope you will enjoy the work over the summer! :-)
>>>> Cheers,
>>>> Matthias
>>>>
>>>>
>>>>
>>>> On Wed, May 10, 2017 at 7:23 PM, Dimitra Zuccarelli <[hidden email]
>>>> <http:///user/SendEmail.jtp?type=node&node=12962&i=1>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'm Dimitra, 21 years old from South Africa/Italy. Im currently
>>>>> studying Applied Computing in Waterford, Ireland. I love programming and
>>>>> similarly to Polina I'm most interested in algorithms, big data and trend
>>>>> analysis.
>>>>>
>>>>> I can't wait to start work on this project and I'm looking forward to
>>>>> getting more involved in the community!
>>>>>
>>>>> On Tue, May 9, 2017 at 3:14 PM, Matthias Wessendorf <[hidden email]
>>>>> <http:///user/SendEmail.jtp?type=node&node=12962&i=2>> wrote:
>>>>>
>>>>>> Hello AeroGear community,
>>>>>>
>>>>>> as the AeroGear project lead, I am thrilled to announce that this
>>>>>> year we do have two students working on the AeroGear UnifiedPush server,
>>>>>> during the Google Summer of Code Projects.
>>>>>>
>>>>>> Both students applied to the "Apache Kafka and Apache HBase"
>>>>>> improvements project, and did deliver a great paper and detailed
>>>>>> implementation plan.
>>>>>>
>>>>>> Over the summer Dimitra and Polina will work with us, in the open, in
>>>>>> the community on this project.
>>>>>>
>>>>>> The main access point for our community is listed here. Most of us do
>>>>>> hang around on IRC, and of course, if there are questions, please send
>>>>>> mails to our mailing list.
>>>>>>
>>>>>> Details:
>>>>>> https://aerogear.org/community/
>>>>>>
>>>>>>
>>>>>> Dimitra, and Polina, I'd like to ask you to introduce yourself here
>>>>>> on this mailing list (remember to subscribe for it), so that the larger
>>>>>> AeroGear community gets to know you better!
>>>>>>
>>>>>> Cheers,
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=3>
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=4>
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> ALI OK
>>>
>>> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com/>
>>> <https://red.ht/sig>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=12962&i=5>
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>> ------------------------------
>>> If you reply to this email, your message will be added to the discussion
>>> below:
>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Googl
>>> e-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12962.html
>>> To start a new topic under aerogear-dev, email [hidden email]
>>> <http:///user/SendEmail.jtp?type=node&node=12964&i=1>
>>> To unsubscribe from aerogear-dev, click here.
>>> NAML
>>> <http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>>
>>>
>>> ------------------------------
>>> View this message in context: Re: [aerogear-dev] Google summer of code:
>>> WELCOME Dimitra and Polina
>>> <http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Google-summer-of-code-WELCOME-Dimitra-and-Polina-tp12952p12964.html>
>>> Sent from the aerogear-dev mailing list archive
>>> <http://aerogear-dev.1069024.n5.nabble.com/> at Nabble.com.
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>>
>> ALI OK
>>
>> SENIOR SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170529/619aa2f8/attachment-0001.html 

From matzew at apache.org  Tue May 30 04:38:56 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 10:38:56 +0200
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAGsbZmEAhU5-JRHd_MGCjb3RxGEisdgKCErcf6QwZdMZJxZ5SA@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
	<CALimhXodxZ+iJ=0-A_fyMoh+L=3cWO4Ton1jvLrUwqgtB618bQ@mail.gmail.com>
	<CAOQ+WrrSD8pe0vCHhrvZE0qv6tKe2WP4Or0mFBhUW3sGvA-OeQ@mail.gmail.com>
	<CAGsbZmEAhU5-JRHd_MGCjb3RxGEisdgKCErcf6QwZdMZJxZ5SA@mail.gmail.com>
Message-ID: <CAAg5f2QhoB+SuuDAzdKHCXPhmEEE323umWV2ExCx_gU8Tb1_PA@mail.gmail.com>

On Fri, May 26, 2017 at 9:48 AM, Jose Miguel Gallas Olmedo <
jgallaso at redhat.com> wrote:

> I say,
>
>
> and then rethinking what value we want to give and how to do it properly.
>
> Just one thing, we need the "pending" state for the UI as a "loading"
> state, from the moment we click the button "send notification" until one of
> the two states you propose is reached.
>

Ok, the server has an "All Batches" loaded event, this one could be used to
implement that.

One problem is, that the "loading" means -> nasty poliing of the server,
until it is "done".
Unfortunately the queries are not that cool, they are a mess, for the
"metrics"

Also, one part of the problem is, that naively the UI aims to be a
real-time UI, which current architecture does not allow us

-M


> ?
>
> On 25 May 2017 at 13:26, Leigh Griffin <lgriffin at redhat.com> wrote:
>
>> +1 to removing it and rethinking the value in what is presented!
>>
>> It could also lead to false assumptions about end device delivery, when
>> in reality it's delivering it to the gateway.
>>
>> On Wed, May 24, 2017 at 4:58 PM, Oleh Mackiv <omatskiv at redhat.com> wrote:
>>
>>> Hi Matthias,
>>> 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't add much value.
>>>
>>> Cheers,
>>> Oleg
>>>
>>> On Wed, May 24, 2017 at 10:30 AM, Matthias Wessendorf <matzew at apache.org
>>> > wrote:
>>>
>>>> Hi,
>>>>
>>>> we do have a problem w/ our current metrics processing. It's
>>>> complicated (lot'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.
>>>>
>>>> I'd like to dramatically simplify our metrics processing... to
>>>> something like:
>>>> Success -> could connect to 3rd party, to deliver tokens
>>>> Failure -> something went wrong when talking to 3rd party service.
>>>>
>>>>
>>>> Right now we do have metrics on push delivery:
>>>> Pending -> the submission to the 3rd party provider is in flight
>>>> Success -> we were able to connect, and could deliver *something*
>>>> Failure -> something obvious, like invalid certificate (APNs), no
>>>> connection to 3rd party possible, etc
>>>>
>>>> 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'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.
>>>>
>>>> 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).
>>>>
>>>> So, for now, I'd like to dramatically simplify the code, and go with
>>>> the above Success/Failure solution.
>>>>
>>>> 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.
>>>>
>>>> This will give us much more freedom and flexibility. Perhaps also, in
>>>> the future, we want some different stats, and something like Prometheus
>>>> /Grafana:
>>>> https://prometheus.io/docs/visualization/grafana/
>>>>
>>>> A more flexible system, with independent metrics 'calculation'
>>>> processing will help us here.
>>>>
>>>> Any thoughts?
>>>>
>>>> -Matthias
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> twitter: http://twitter.com/mwessendorfa
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Oleg Matskiv
>>> Associate Quality Engineer
>>> Red Hat Mobile Application Platform
>>> omatskiv at redhat.com
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>>
>> LEIGH GRIFFIN
>>
>> ENGINEERING MANAGER, MOBILE
>>
>> Red Hat Ireland <https://www.redhat.com/>
>>
>> Communications House, Cork Road
>>
>> Waterford City, Ireland X91NY33
>>
>> lgriffin at redhat.com    M: +353877545162     IM: lgriffin
>> <https://red.ht/sig>
>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>
>> @redhatway <https://twitter.com/redhatway>   @redhatinc
>> <https://instagram.com/redhatinc>   @redhatsnaps
>> <https://snapchat.com/add/redhatsnaps>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/b77ba1bf/attachment.html 

From supittma at redhat.com  Tue May 30 08:06:21 2017
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 30 May 2017 08:06:21 -0400
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
Message-ID: <CAEQz2CvPa4Q=q+uKh18DP5R1MRAF8YdEBaVNab+bkc7Fox8iPQ@mail.gmail.com>

On Wed, May 24, 2017 at 4:30 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> we do have a problem w/ our current metrics processing. It's complicated
> (lot'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.
>
> I'd like to dramatically simplify our metrics processing... to something
> like:
> Success -> could connect to 3rd party, to deliver tokens
> Failure -> something went wrong when talking to 3rd party service.
>
>
> Right now we do have metrics on push delivery:
> Pending -> the submission to the 3rd party provider is in flight
> Success -> we were able to connect, and could deliver *something*
> Failure -> something obvious, like invalid certificate (APNs), no
> connection to 3rd party possible, etc
>
> 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'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.
>
> 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).
>
> So, for now, I'd like to dramatically simplify the code, and go with the
> above Success/Failure solution.
>
> 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.
>
> This will give us much more freedom and flexibility. Perhaps also, in the
> future, we want some different stats, and something like Prometheus
> /Grafana:
> https://prometheus.io/docs/visualization/grafana/
>
> A more flexible system, with independent metrics 'calculation' processing
> will help us here.
>
> Any thoughts?
>
>
What if we remove the current metrics UI and replace them with webhooks
that emit events?  It lets us add events easily, somewhat simplifies
debugging, and gives integrators a lot more control and hooks into our
process.  We can even turn the current metrics into a microservice project
as an example.  (Doubly so when we get Keycloak broken out and properly
integrated)


> -Matthias
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorfa
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/e666a5fb/attachment-0001.html 

From matzew at apache.org  Tue May 30 08:43:46 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 14:43:46 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
Message-ID: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>

Hi,

on FCM related push, we do, in our client SDK, automatically subscribe a
client to an annoymous topic, matching our immutable variant ID.

If users are specifying categories, we do map those into topics as well.

This is the related code in our Android SDK:
https://github.com/aerogear/aerogear-android-push/blob/master/aerogear-android-push/src/main/java/org/jboss/aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193

How do people feel about doing that for the alias as well ?

In the past we did not do it, since topics used to be a more restricted
resource. Remember, the first notion of topics (GCM v3, at that time) were
even limiting the number of max. subscribers?

However, that changed, and I think it would be nice if we just use the
topics for each alias of the app as well. This would speed up the time to
deliver the push request to the FCM backend, since the UPS would no longer
need to look up the device, a push, regardless how many devices, means one
small HTTP to Google, per alias (aka topic)

Any thoughts ?

NOTE: There is a general limit of topic abuse, but that's on the app
instance (see [1]), so our APP Developers need to make sure they don't go
crazy w/ a gazillion of categories ;-)

-Matthias


[1] https://firebase.google.com/docs/cloud-messaging/admin/errors

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/e8a39281/attachment.html 

From omatskiv at redhat.com  Tue May 30 09:32:42 2017
From: omatskiv at redhat.com (Oleh Mackiv)
Date: Tue, 30 May 2017 15:32:42 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
Message-ID: <CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>

Hi,
I think this very much depends on what is the actual limit for number of
topics.

Consider this use case, that would max out topics very quickly:
- register alias for each user
- if user has multiple devices, all his devices will have same alias
- if you want to notify some user, you just send notification to his alias
and UPS will distribute it to all devices that this user has registere

We even suggest this in docs[1]:
"alias: A list of one or more *identifiers* (such as email or username) to
send messages to *ALL* devices of the user(s)"


P.S: Do you know how much topics you can actually register before you hit
the "messaging/too-many-topics" error ?


[1]
https://aerogear.org/docs/unifiedpush/push-message-format/#query-component



On Tue, May 30, 2017 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> on FCM related push, we do, in our client SDK, automatically subscribe a
> client to an annoymous topic, matching our immutable variant ID.
>
> If users are specifying categories, we do map those into topics as well.
>
> This is the related code in our Android SDK:
> https://github.com/aerogear/aerogear-android-push/blob/
> master/aerogear-android-push/src/main/java/org/jboss/
> aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>
> How do people feel about doing that for the alias as well ?
>
> In the past we did not do it, since topics used to be a more restricted
> resource. Remember, the first notion of topics (GCM v3, at that time) were
> even limiting the number of max. subscribers?
>
> However, that changed, and I think it would be nice if we just use the
> topics for each alias of the app as well. This would speed up the time to
> deliver the push request to the FCM backend, since the UPS would no longer
> need to look up the device, a push, regardless how many devices, means one
> small HTTP to Google, per alias (aka topic)
>
> Any thoughts ?
>
> NOTE: There is a general limit of topic abuse, but that's on the app
> instance (see [1]), so our APP Developers need to make sure they don't go
> crazy w/ a gazillion of categories ;-)
>
> -Matthias
>
>
> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
omatskiv at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/31273e6c/attachment.html 

From dpassos at redhat.com  Tue May 30 09:33:01 2017
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 30 May 2017 10:33:01 -0300
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
Message-ID: <CADF=h2uVDqOdSU_FrXsEB-koGfcpdZEQJXuLGsAF+qPoJ=zCGQ@mail.gmail.com>

On Tue, May 30, 2017 at 9:43 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> on FCM related push, we do, in our client SDK, automatically subscribe a
> client to an annoymous topic, matching our immutable variant ID.
>
> If users are specifying categories, we do map those into topics as well.
>
> This is the related code in our Android SDK:
> https://github.com/aerogear/aerogear-android-push/blob/
> master/aerogear-android-push/src/main/java/org/jboss/
> aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>
> How do people feel about doing that for the alias as well ?
>

I really like that idea.


>
> In the past we did not do it, since topics used to be a more restricted
> resource. Remember, the first notion of topics (GCM v3, at that time) were
> even limiting the number of max. subscribers?
>

> However, that changed, and I think it would be nice if we just use the
> topics for each alias of the app as well. This would speed up the time to
> deliver the push request to the FCM backend, since the UPS would no longer
> need to look up the device, a push, regardless how many devices, means one
> small HTTP to Google, per alias (aka topic)
>
> Any thoughts ?
>
> NOTE: There is a general limit of topic abuse, but that's on the app
> instance (see [1]), so our APP Developers need to make sure they don't go
> crazy w/ a gazillion of categories ;-)
>

Just a heads up about topics limit =>
https://stackoverflow.com/questions/38171259/maximum-number-of-topics-a-device-can-subscribe-to-in-fcm


>
> -Matthias
>
>
> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/1834f67a/attachment.html 

From supittma at redhat.com  Tue May 30 10:04:19 2017
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 30 May 2017 10:04:19 -0400
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
Message-ID: <CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>

On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> on FCM related push, we do, in our client SDK, automatically subscribe a
> client to an annoymous topic, matching our immutable variant ID.
>
> If users are specifying categories, we do map those into topics as well.
>
> This is the related code in our Android SDK:
> https://github.com/aerogear/aerogear-android-push/blob/
> master/aerogear-android-push/src/main/java/org/jboss/
> aerogear/android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>
> How do people feel about doing that for the alias as well ?
>
> In the past we did not do it, since topics used to be a more restricted
> resource. Remember, the first notion of topics (GCM v3, at that time) were
> even limiting the number of max. subscribers?
>
> However, that changed, and I think it would be nice if we just use the
> topics for each alias of the app as well. This would speed up the time to
> deliver the push request to the FCM backend, since the UPS would no longer
> need to look up the device, a push, regardless how many devices, means one
> small HTTP to Google, per alias (aka topic)
>
> Any thoughts ?
>

So there is a concept of "device groups" in FCM which are devices owned by
the same logical user.  I think that might be a more interesting knob to
twist than more stuff on a topic.

Also we might want to start considering how we can handle keeping
notifications in sync across devices.  FCM has capabilities for sending
"read receipts" to other devices to dismiss notifications that were handled
on a different device and I think it leans on the device group APIs I
mentioned to do that.  But this is all based on my feeble memory ;)


>
> NOTE: There is a general limit of topic abuse, but that's on the app
> instance (see [1]), so our APP Developers need to make sure they don't go
> crazy w/ a gazillion of categories ;-)
>
> -Matthias
>
>
> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/99568f76/attachment-0001.html 

From supittma at redhat.com  Tue May 30 10:20:18 2017
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 30 May 2017 10:20:18 -0400
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
Message-ID: <CAEQz2CtYeb9BvZBTE2nynBEFa1LCM=D_tRxKCBmNrxi-USgxBw@mail.gmail.com>

On Tue, May 30, 2017 at 9:32 AM, Oleh Mackiv <omatskiv at redhat.com> wrote:

> Hi,
> I think this very much depends on what is the actual limit for number of
> topics.
>
> Consider this use case, that would max out topics very quickly:
> - register alias for each user
> - if user has multiple devices, all his devices will have same alias
> - if you want to notify some user, you just send notification to his alias
> and UPS will distribute it to all devices that this user has registere
>
> We even suggest this in docs[1]:
> "alias: A list of one or more *identifiers* (such as email or username)
> to send messages to *ALL* devices of the user(s)"
>
>
> P.S: Do you know how much topics you can actually register before you hit
> the "messaging/too-many-topics" error ?
>

I think it isn't set.  Google has not been very open with the limits on the
topic mechanism. (At one point there was a one million subscriber limit).
Regardless, I think we can probably beef up UPS to fall back to standard
sending mechanisms if we get errors, it can eve be part of our value add.


>
>
> [1] https://aerogear.org/docs/unifiedpush/push-message-
> format/#query-component
>
>
>
> On Tue, May 30, 2017 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Oleg Matskiv
> Associate Quality Engineer
> Red Hat Mobile Application Platform
> omatskiv at redhat.com
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/d735fc35/attachment.html 

From omatskiv at redhat.com  Tue May 30 10:29:01 2017
From: omatskiv at redhat.com (Oleh Mackiv)
Date: Tue, 30 May 2017 16:29:01 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CADF=h2uVDqOdSU_FrXsEB-koGfcpdZEQJXuLGsAF+qPoJ=zCGQ@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CADF=h2uVDqOdSU_FrXsEB-koGfcpdZEQJXuLGsAF+qPoJ=zCGQ@mail.gmail.com>
Message-ID: <CALimhXqniNFpWGBeP3nQ8H9sbPDqPQVHvtu062UedvQvU606dQ@mail.gmail.com>

I just read about the limit again, and since its per app instance(!), you
can disregard my previous reply. Sorry about that.

+1 on using topics for android aliases :)

On Tue, May 30, 2017 at 3:33 PM, Daniel Passos <dpassos at redhat.com> wrote:

>
>
> On Tue, May 30, 2017 at 9:43 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>
> I really like that idea.
>
>
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>
> Just a heads up about topics limit => https://stackoverflow.com/
> questions/38171259/maximum-number-of-topics-a-device-can-
> subscribe-to-in-fcm
>
>
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Oleg Matskiv
Associate Quality Engineer
Red Hat Mobile Application Platform
omatskiv at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/3474525c/attachment.html 

From matzew at apache.org  Tue May 30 10:50:45 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 16:50:45 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
Message-ID: <CAAg5f2TdcrmRfOQuK2BZ=huk+cmctnxzXapo+xW1AOPJTfZjpA@mail.gmail.com>

On Tue, May 30, 2017 at 3:32 PM, Oleh Mackiv <omatskiv at redhat.com> wrote:

> Hi,
> I think this very much depends on what is the actual limit for number of
> topics.
>
> Consider this use case, that would max out topics very quickly:
> - register alias for each user
>

that's the idea ;-)

the limit from Google is on the client. If one device subscribs itself to
all users... well, there is a bug in the app.
the app itself is not rejected when assigning a token from FCM.  It's not
the server




> - if user has multiple devices, all his devices will have same alias
>

that's the idea


> - if you want to notify some user, you just send notification to his alias
> and UPS will distribute it to all devices that this user has registere
>

through that user topic




>
> We even suggest this in docs[1]:
> "alias: A list of one or more *identifiers* (such as email or username)
> to send messages to *ALL* devices of the user(s)"
>
>
> P.S: Do you know how much topics you can actually register before you hit
> the "messaging/too-many-topics" error ?
>

For sanity it's not documented ;-) I guess it's not that small - since
major news apps in the US are using that feature to distribute pushes, for
... news topics

>
>
> [1] https://aerogear.org/docs/unifiedpush/push-message-
> format/#query-component
>
>
>
> On Tue, May 30, 2017 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Oleg Matskiv
> Associate Quality Engineer
> Red Hat Mobile Application Platform
> omatskiv at redhat.com
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/49fef5da/attachment-0001.html 

From matzew at apache.org  Tue May 30 10:52:12 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 16:52:12 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CADF=h2uVDqOdSU_FrXsEB-koGfcpdZEQJXuLGsAF+qPoJ=zCGQ@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CADF=h2uVDqOdSU_FrXsEB-koGfcpdZEQJXuLGsAF+qPoJ=zCGQ@mail.gmail.com>
Message-ID: <CAAg5f2TR+oeJ9snY3JrAbe5QO20dm7pUWdm9u_E31tCYyLN7Eg@mail.gmail.com>

On Tue, May 30, 2017 at 3:33 PM, Daniel Passos <dpassos at redhat.com> wrote:

>
>
> On Tue, May 30, 2017 at 9:43 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>
> I really like that idea.
>
>
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>
> Just a heads up about topics limit => https://stackoverflow.com/
> questions/38171259/maximum-number-of-topics-a-device-can-
> subscribe-to-in-fcm
>

Right, it's per device, not for per server-key

Alias is usually one per device - Categories, which we are already do via
topics, do definitely have more room here:
music, sports, beer, burgers, linux, jboss, and so on ;-)




>
>
>
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/7c2e987f/attachment.html 

From matzew at apache.org  Tue May 30 11:27:58 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 17:27:58 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
Message-ID: <CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>

On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>
> So there is a concept of "device groups" in FCM which are devices owned by
> the same logical user.  I think that might be a more interesting knob to
> twist than more stuff on a topic.
>

any link ? ;-)


>
> Also we might want to start considering how we can handle keeping
> notifications in sync across devices.  FCM has capabilities for sending
> "read receipts" to other devices to dismiss notifications that were handled
> on a different device and I think it leans on the device group APIs I
> mentioned to do that.  But this is all based on my feeble memory ;)
>

for sure, something we could do in the future, with a new server component.
i dont want ups to keep track of all of that.

ideally push just sends push... and writes status to kafka, than others
read and do what they want, e.g. metrics, sync etc


>
>
>>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/e19ffd10/attachment.html 

From dpassos at redhat.com  Tue May 30 12:00:26 2017
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 30 May 2017 13:00:26 -0300
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
Message-ID: <CADF=h2uN+dh-FKc8cxNLn_KjE+QMYSop9fo1gM+c5SjnVbvuSg@mail.gmail.com>

On Tue, May 30, 2017 at 10:32 AM, Oleh Mackiv <omatskiv at redhat.com> wrote:

> Hi,
> I think this very much depends on what is the actual limit for number of
> topics.
>
> Consider this use case, that would max out topics very quickly:
> - register alias for each user
> - if user has multiple devices, all his devices will have same alias
> - if you want to notify some user, you just send notification to his alias
> and UPS will distribute it to all devices that this user has registere
>
> We even suggest this in docs[1]:
> "alias: A list of one or more *identifiers* (such as email or username)
> to send messages to *ALL* devices of the user(s)"
>
>
> P.S: Do you know how much topics you can actually register before you hit
> the "messaging/too-many-topics" error ?
>


There is no magic number. It will raise the max if you are "spam" the
server :/

https://stackoverflow.com/questions/38171259/maximum-number-of-topics-a-device-can-subscribe-to-in-fcm


>
>
> [1] https://aerogear.org/docs/unifiedpush/push-message-
> format/#query-component
>
>
>
> On Tue, May 30, 2017 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Oleg Matskiv
> Associate Quality Engineer
> Red Hat Mobile Application Platform
> omatskiv at redhat.com
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/c164c371/attachment-0001.html 

From dpassos at redhat.com  Tue May 30 12:01:47 2017
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 30 May 2017 13:01:47 -0300
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
Message-ID: <CADF=h2vUZpCuHyqng7n-ZnqXsjUvrVjAQVzTSmD2ps=LD=esxQ@mail.gmail.com>

On Tue, May 30, 2017 at 11:04 AM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> on FCM related push, we do, in our client SDK, automatically subscribe a
>> client to an annoymous topic, matching our immutable variant ID.
>>
>> If users are specifying categories, we do map those into topics as well.
>>
>> This is the related code in our Android SDK:
>> https://github.com/aerogear/aerogear-android-push/blob/maste
>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/
>> android/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>
>> How do people feel about doing that for the alias as well ?
>>
>> In the past we did not do it, since topics used to be a more restricted
>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>> even limiting the number of max. subscribers?
>>
>> However, that changed, and I think it would be nice if we just use the
>> topics for each alias of the app as well. This would speed up the time to
>> deliver the push request to the FCM backend, since the UPS would no longer
>> need to look up the device, a push, regardless how many devices, means one
>> small HTTP to Google, per alias (aka topic)
>>
>> Any thoughts ?
>>
>
> So there is a concept of "device groups" in FCM which are devices owned by
> the same logical user.  I think that might be a more interesting knob to
> twist than more stuff on a topic.
>
> Also we might want to start considering how we can handle keeping
> notifications in sync across devices.  FCM has capabilities for sending
> "read receipts" to other devices to dismiss notifications that were handled
> on a different device and I think it leans on the device group APIs I
> mentioned to do that.  But this is all based on my feeble memory ;)
>


I totally forgot about that. For sure it will be a best solution specially
about notify the other devices the message was already consumed


>
>> NOTE: There is a general limit of topic abuse, but that's on the app
>> instance (see [1]), so our APP Developers need to make sure they don't go
>> crazy w/ a gazillion of categories ;-)
>>
>> -Matthias
>>
>>
>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> 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
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/5a6c96c9/attachment.html 

From matzew at apache.org  Tue May 30 12:40:56 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 18:40:56 +0200
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAEQz2CvPa4Q=q+uKh18DP5R1MRAF8YdEBaVNab+bkc7Fox8iPQ@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
	<CAEQz2CvPa4Q=q+uKh18DP5R1MRAF8YdEBaVNab+bkc7Fox8iPQ@mail.gmail.com>
Message-ID: <CAAg5f2SJ4tai7GEEn0wyQp9M7jz_9d9xbb_bT+QYnyDE6w8kMw@mail.gmail.com>

On Tue, May 30, 2017 at 2:06 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Wed, May 24, 2017 at 4:30 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> we do have a problem w/ our current metrics processing. It's complicated
>> (lot'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.
>>
>> I'd like to dramatically simplify our metrics processing... to something
>> like:
>> Success -> could connect to 3rd party, to deliver tokens
>> Failure -> something went wrong when talking to 3rd party service.
>>
>>
>> Right now we do have metrics on push delivery:
>> Pending -> the submission to the 3rd party provider is in flight
>> Success -> we were able to connect, and could deliver *something*
>> Failure -> something obvious, like invalid certificate (APNs), no
>> connection to 3rd party possible, etc
>>
>> 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'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.
>>
>> 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).
>>
>> So, for now, I'd like to dramatically simplify the code, and go with the
>> above Success/Failure solution.
>>
>> 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.
>>
>> This will give us much more freedom and flexibility. Perhaps also, in the
>> future, we want some different stats, and something like Prometheus
>> /Grafana:
>> https://prometheus.io/docs/visualization/grafana/
>>
>> A more flexible system, with independent metrics 'calculation' processing
>> will help us here.
>>
>> Any thoughts?
>>
>>
> What if we remove the current metrics UI
>

For sanity, we are also simplifying the UI:
https://issues.jboss.org/browse/AGPUSH-2090


> and replace them with webhooks that emit events?
>

In the long run, I am open to anything else. I think I mainly care about
the actual push delivery and the events that we will be submitting to a
centralized data hub/pipeline, such as Kafka.

>From there, a consumer process (written in what ever language) can offer
webhooks etc


>   It lets us add events easily, somewhat simplifies debugging, and gives
> integrators a lot more control and hooks into our process.  We can even
> turn the current metrics into a microservice project as an example.
>  (Doubly so when we get Keycloak broken out and properly integrated)
>

the overall idea is to break the server in to a more modular system:
* push-sender.war
* metrics-processor.war (or jar)
* device-regitration.war
* UI process

I think decoupled keycloak would be also key to this, or what do you mean ?



>
>
>> -Matthias
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorfa
>>
>> _______________________________________________
>> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/3b2ebdb3/attachment.html 

From dpassos at redhat.com  Tue May 30 13:23:15 2017
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 30 May 2017 14:23:15 -0300
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
	<CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
Message-ID: <CADF=h2uCeM5dzY4QGDv6+8aBTBEOgkvG_HHeezAqO4Zq7ZXekA@mail.gmail.com>

On Tue, May 30, 2017 at 12:27 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> on FCM related push, we do, in our client SDK, automatically subscribe a
>>> client to an annoymous topic, matching our immutable variant ID.
>>>
>>> If users are specifying categories, we do map those into topics as well.
>>>
>>> This is the related code in our Android SDK:
>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>
>>> How do people feel about doing that for the alias as well ?
>>>
>>> In the past we did not do it, since topics used to be a more restricted
>>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>>> even limiting the number of max. subscribers?
>>>
>>> However, that changed, and I think it would be nice if we just use the
>>> topics for each alias of the app as well. This would speed up the time to
>>> deliver the push request to the FCM backend, since the UPS would no longer
>>> need to look up the device, a push, regardless how many devices, means one
>>> small HTTP to Google, per alias (aka topic)
>>>
>>> Any thoughts ?
>>>
>>
>> So there is a concept of "device groups" in FCM which are devices owned
>> by the same logical user.  I think that might be a more interesting knob to
>> twist than more stuff on a topic.
>>
>
> any link ? ;-)
>


https://firebase.google.com/docs/cloud-messaging/android/device-group



>
>> Also we might want to start considering how we can handle keeping
>> notifications in sync across devices.  FCM has capabilities for sending
>> "read receipts" to other devices to dismiss notifications that were handled
>> on a different device and I think it leans on the device group APIs I
>> mentioned to do that.  But this is all based on my feeble memory ;)
>>
>
> for sure, something we could do in the future, with a new server
> component. i dont want ups to keep track of all of that.
>
> ideally push just sends push... and writes status to kafka, than others
> read and do what they want, e.g. metrics, sync etc
>
>
>>
>>
>>>
>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>> crazy w/ a gazillion of categories ;-)
>>>
>>> -Matthias
>>>
>>>
>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> 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/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/e3b6e194/attachment-0001.html 

From dpassos at redhat.com  Tue May 30 13:26:55 2017
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 30 May 2017 14:26:55 -0300
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
	<CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
Message-ID: <CADF=h2ugN_UZ_RWCLNnhMP0+qM2AzLWkFd3=-wnE20thooDO6g@mail.gmail.com>

On Tue, May 30, 2017 at 12:27 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> on FCM related push, we do, in our client SDK, automatically subscribe a
>>> client to an annoymous topic, matching our immutable variant ID.
>>>
>>> If users are specifying categories, we do map those into topics as well.
>>>
>>> This is the related code in our Android SDK:
>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>
>>> How do people feel about doing that for the alias as well ?
>>>
>>> In the past we did not do it, since topics used to be a more restricted
>>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>>> even limiting the number of max. subscribers?
>>>
>>> However, that changed, and I think it would be nice if we just use the
>>> topics for each alias of the app as well. This would speed up the time to
>>> deliver the push request to the FCM backend, since the UPS would no longer
>>> need to look up the device, a push, regardless how many devices, means one
>>> small HTTP to Google, per alias (aka topic)
>>>
>>> Any thoughts ?
>>>
>>
>> So there is a concept of "device groups" in FCM which are devices owned
>> by the same logical user.  I think that might be a more interesting knob to
>> twist than more stuff on a topic.
>>
>
> any link ? ;-)
>


https://firebase.google.com/docs/cloud-messaging/android/device-group
https://youtu.be/gJatfdattno?t=679


>
>
>>
>> Also we might want to start considering how we can handle keeping
>> notifications in sync across devices.  FCM has capabilities for sending
>> "read receipts" to other devices to dismiss notifications that were handled
>> on a different device and I think it leans on the device group APIs I
>> mentioned to do that.  But this is all based on my feeble memory ;)
>>
>
> for sure, something we could do in the future, with a new server
> component. i dont want ups to keep track of all of that.
>
> ideally push just sends push... and writes status to kafka, than others
> read and do what they want, e.g. metrics, sync etc
>
>
>>
>>
>>>
>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>> crazy w/ a gazillion of categories ;-)
>>>
>>> -Matthias
>>>
>>>
>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> 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/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/0f16804c/attachment.html 

From supittma at redhat.com  Tue May 30 13:33:50 2017
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 30 May 2017 13:33:50 -0400
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
	<CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
Message-ID: <CAEQz2CuaTyDTvopXSVWUsHdftWe_6h6k21mftJo6GL0ZmD+YcQ@mail.gmail.com>

On Tue, May 30, 2017 at 11:27 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> on FCM related push, we do, in our client SDK, automatically subscribe a
>>> client to an annoymous topic, matching our immutable variant ID.
>>>
>>> If users are specifying categories, we do map those into topics as well.
>>>
>>> This is the related code in our Android SDK:
>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>
>>> How do people feel about doing that for the alias as well ?
>>>
>>> In the past we did not do it, since topics used to be a more restricted
>>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>>> even limiting the number of max. subscribers?
>>>
>>> However, that changed, and I think it would be nice if we just use the
>>> topics for each alias of the app as well. This would speed up the time to
>>> deliver the push request to the FCM backend, since the UPS would no longer
>>> need to look up the device, a push, regardless how many devices, means one
>>> small HTTP to Google, per alias (aka topic)
>>>
>>> Any thoughts ?
>>>
>>
>> So there is a concept of "device groups" in FCM which are devices owned
>> by the same logical user.  I think that might be a more interesting knob to
>> twist than more stuff on a topic.
>>
>
> any link ? ;-)
>
>

So I think I might be overstating and misremembering, but this :
https://firebase.google.com/docs/cloud-messaging/android/device-group#sending_upstream_messages_to_device_groups
looks promising.  Basically if I am reading the doc right I can send a
message from one device to the others using device groups, and this message
could be a read receipt that closes the other notifications when it is
received.


>
>> Also we might want to start considering how we can handle keeping
>> notifications in sync across devices.  FCM has capabilities for sending
>> "read receipts" to other devices to dismiss notifications that were handled
>> on a different device and I think it leans on the device group APIs I
>> mentioned to do that.  But this is all based on my feeble memory ;)
>>
>
> for sure, something we could do in the future, with a new server
> component. i dont want ups to keep track of all of that.
>
> ideally push just sends push... and writes status to kafka, than others
> read and do what they want, e.g. metrics, sync etc
>
>
>>
>>
>>>
>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>> crazy w/ a gazillion of categories ;-)
>>>
>>> -Matthias
>>>
>>>
>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> 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/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/5ab34aa0/attachment.html 

From matzew at apache.org  Tue May 30 14:35:00 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 30 May 2017 20:35:00 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CADF=h2uN+dh-FKc8cxNLn_KjE+QMYSop9fo1gM+c5SjnVbvuSg@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CALimhXohc3AfYLbP0xwkKVghcOWbmMbBR9MrYQOVHrkdbioPAA@mail.gmail.com>
	<CADF=h2uN+dh-FKc8cxNLn_KjE+QMYSop9fo1gM+c5SjnVbvuSg@mail.gmail.com>
Message-ID: <CAAg5f2S4KN+YJBMDWhHwnxpEHBsGuuvM2VBjCOKuYHPry0bCbg@mail.gmail.com>

On Tue, May 30, 2017 at 6:00 PM, Daniel Passos <dpassos at redhat.com> wrote:

>
>
> On Tue, May 30, 2017 at 10:32 AM, Oleh Mackiv <omatskiv at redhat.com> wrote:
>
>> Hi,
>> I think this very much depends on what is the actual limit for number of
>> topics.
>>
>> Consider this use case, that would max out topics very quickly:
>> - register alias for each user
>> - if user has multiple devices, all his devices will have same alias
>> - if you want to notify some user, you just send notification to his
>> alias and UPS will distribute it to all devices that this user has registere
>>
>> We even suggest this in docs[1]:
>> "alias: A list of one or more *identifiers* (such as email or username)
>> to send messages to *ALL* devices of the user(s)"
>>
>>
>> P.S: Do you know how much topics you can actually register before you hit
>> the "messaging/too-many-topics" error ?
>>
>
>
> There is no magic number. It will raise the max if you are "spam" the
> server :/
>
> https://stackoverflow.com/questions/38171259/maximum-
> number-of-topics-a-device-can-subscribe-to-in-fcm
>

yep, that's currently already a problem, due to each category is mapped to
one topic.
It's a responsiblity on the app developer to let the mobile app not go
crazy.

>From server point of view, it's not an issue


>
>
>
>>
>>
>> [1] https://aerogear.org/docs/unifiedpush/push-message-format/#
>> query-component
>>
>>
>>
>> On Tue, May 30, 2017 at 2:43 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> on FCM related push, we do, in our client SDK, automatically subscribe a
>>> client to an annoymous topic, matching our immutable variant ID.
>>>
>>> If users are specifying categories, we do map those into topics as well.
>>>
>>> This is the related code in our Android SDK:
>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>
>>> How do people feel about doing that for the alias as well ?
>>>
>>> In the past we did not do it, since topics used to be a more restricted
>>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>>> even limiting the number of max. subscribers?
>>>
>>> However, that changed, and I think it would be nice if we just use the
>>> topics for each alias of the app as well. This would speed up the time to
>>> deliver the push request to the FCM backend, since the UPS would no longer
>>> need to look up the device, a push, regardless how many devices, means one
>>> small HTTP to Google, per alias (aka topic)
>>>
>>> Any thoughts ?
>>>
>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>> crazy w/ a gazillion of categories ;-)
>>>
>>> -Matthias
>>>
>>>
>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Oleg Matskiv
>> Associate Quality Engineer
>> Red Hat Mobile Application Platform
>> omatskiv at redhat.com
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/ce3c67d1/attachment-0001.html 

From dpassos at redhat.com  Tue May 30 16:33:50 2017
From: dpassos at redhat.com (Daniel Passos)
Date: Tue, 30 May 2017 17:33:50 -0300
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CAEQz2CuaTyDTvopXSVWUsHdftWe_6h6k21mftJo6GL0ZmD+YcQ@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
	<CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
	<CAEQz2CuaTyDTvopXSVWUsHdftWe_6h6k21mftJo6GL0ZmD+YcQ@mail.gmail.com>
Message-ID: <CADF=h2s8Atx3Yu15g5wOCDdJGwFjmcmAdY1PLWpajR1tp=79ag@mail.gmail.com>

On Tue, May 30, 2017 at 2:33 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Tue, May 30, 2017 at 11:27 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> on FCM related push, we do, in our client SDK, automatically subscribe
>>>> a client to an annoymous topic, matching our immutable variant ID.
>>>>
>>>> If users are specifying categories, we do map those into topics as well.
>>>>
>>>> This is the related code in our Android SDK:
>>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>>
>>>> How do people feel about doing that for the alias as well ?
>>>>
>>>> In the past we did not do it, since topics used to be a more restricted
>>>> resource. Remember, the first notion of topics (GCM v3, at that time) were
>>>> even limiting the number of max. subscribers?
>>>>
>>>> However, that changed, and I think it would be nice if we just use the
>>>> topics for each alias of the app as well. This would speed up the time to
>>>> deliver the push request to the FCM backend, since the UPS would no longer
>>>> need to look up the device, a push, regardless how many devices, means one
>>>> small HTTP to Google, per alias (aka topic)
>>>>
>>>> Any thoughts ?
>>>>
>>>
>>> So there is a concept of "device groups" in FCM which are devices owned
>>> by the same logical user.  I think that might be a more interesting knob to
>>> twist than more stuff on a topic.
>>>
>>
>> any link ? ;-)
>>
>>
>
> So I think I might be overstating and misremembering, but this :
> https://firebase.google.com/docs/cloud-messaging/android/
> device-group#sending_upstream_messages_to_device_groups looks promising.
> Basically if I am reading the doc right I can send a message from one
> device to the others using device groups, and this message could be a read
> receipt that closes the other notifications when it is received.
>

I think you are right, it isn't some UPS should but, it's something device
will do.
More detail in the video => https://youtu.be/gJatfdattno?t=675



>
>>> Also we might want to start considering how we can handle keeping
>>> notifications in sync across devices.  FCM has capabilities for sending
>>> "read receipts" to other devices to dismiss notifications that were handled
>>> on a different device and I think it leans on the device group APIs I
>>> mentioned to do that.  But this is all based on my feeble memory ;)
>>>
>>
>> for sure, something we could do in the future, with a new server
>> component. i dont want ups to keep track of all of that.
>>
>> ideally push just sends push... and writes status to kafka, than others
>> read and do what they want, e.g. metrics, sync etc
>>
>>
>>>
>>>
>>>>
>>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>>> crazy w/ a gazillion of categories ;-)
>>>>
>>>> -Matthias
>>>>
>>>>
>>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> 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/
>> 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
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170530/28dae86c/attachment.html 

From matzew at apache.org  Wed May 31 03:22:48 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 31 May 2017 09:22:48 +0200
Subject: [aerogear-dev] FCM topic: use on alias as well ?
In-Reply-To: <CADF=h2s8Atx3Yu15g5wOCDdJGwFjmcmAdY1PLWpajR1tp=79ag@mail.gmail.com>
References: <CAAg5f2T+7xwbYOO2zM5o_9uf=cj45R=-QV2tsuue46a4Pgu2Yw@mail.gmail.com>
	<CAEQz2Cu0a_jg2qtgbW+1eu+8rq=70A0tLa6ZOCqq5hmGgDty2Q@mail.gmail.com>
	<CAAg5f2S1qS2i-kndYFL-Xe-XCCxU+e6fMNWLNTT4mceO2Ky8Pw@mail.gmail.com>
	<CAEQz2CuaTyDTvopXSVWUsHdftWe_6h6k21mftJo6GL0ZmD+YcQ@mail.gmail.com>
	<CADF=h2s8Atx3Yu15g5wOCDdJGwFjmcmAdY1PLWpajR1tp=79ag@mail.gmail.com>
Message-ID: <CAAg5f2S5y+O4RfnN5NU9fW49b9sWs90d+u5W=jOnEykeq9+=zA@mail.gmail.com>

Hi, all,

I've created an epic for this:
https://issues.jboss.org/browse/AGPUSH-2093

Cheers,
Matthias

On Tue, May 30, 2017 at 10:33 PM, Daniel Passos <dpassos at redhat.com> wrote:

>
>
> On Tue, May 30, 2017 at 2:33 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Tue, May 30, 2017 at 11:27 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>>
>>>
>>> On Tue, May 30, 2017 at 4:04 PM, Summers Pittman <supittma at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 30, 2017 at 8:43 AM, Matthias Wessendorf <matzew at apache.org
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> on FCM related push, we do, in our client SDK, automatically subscribe
>>>>> a client to an annoymous topic, matching our immutable variant ID.
>>>>>
>>>>> If users are specifying categories, we do map those into topics as
>>>>> well.
>>>>>
>>>>> This is the related code in our Android SDK:
>>>>> https://github.com/aerogear/aerogear-android-push/blob/maste
>>>>> r/aerogear-android-push/src/main/java/org/jboss/aerogear/and
>>>>> roid/unifiedpush/fcm/AeroGearFCMPushRegistrar.java#L188-L193
>>>>>
>>>>> How do people feel about doing that for the alias as well ?
>>>>>
>>>>> In the past we did not do it, since topics used to be a more
>>>>> restricted resource. Remember, the first notion of topics (GCM v3, at that
>>>>> time) were even limiting the number of max. subscribers?
>>>>>
>>>>> However, that changed, and I think it would be nice if we just use the
>>>>> topics for each alias of the app as well. This would speed up the time to
>>>>> deliver the push request to the FCM backend, since the UPS would no longer
>>>>> need to look up the device, a push, regardless how many devices, means one
>>>>> small HTTP to Google, per alias (aka topic)
>>>>>
>>>>> Any thoughts ?
>>>>>
>>>>
>>>> So there is a concept of "device groups" in FCM which are devices owned
>>>> by the same logical user.  I think that might be a more interesting knob to
>>>> twist than more stuff on a topic.
>>>>
>>>
>>> any link ? ;-)
>>>
>>>
>>
>> So I think I might be overstating and misremembering, but this :
>> https://firebase.google.com/docs/cloud-messaging/android/d
>> evice-group#sending_upstream_messages_to_device_groups looks promising.
>> Basically if I am reading the doc right I can send a message from one
>> device to the others using device groups, and this message could be a read
>> receipt that closes the other notifications when it is received.
>>
>
> I think you are right, it isn't some UPS should but, it's something device
> will do.
> More detail in the video => https://youtu.be/gJatfdattno?t=675
>
>
>
>>
>>>> Also we might want to start considering how we can handle keeping
>>>> notifications in sync across devices.  FCM has capabilities for sending
>>>> "read receipts" to other devices to dismiss notifications that were handled
>>>> on a different device and I think it leans on the device group APIs I
>>>> mentioned to do that.  But this is all based on my feeble memory ;)
>>>>
>>>
>>> for sure, something we could do in the future, with a new server
>>> component. i dont want ups to keep track of all of that.
>>>
>>> ideally push just sends push... and writes status to kafka, than others
>>> read and do what they want, e.g. metrics, sync etc
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> NOTE: There is a general limit of topic abuse, but that's on the app
>>>>> instance (see [1]), so our APP Developers need to make sure they don't go
>>>>> crazy w/ a gazillion of categories ;-)
>>>>>
>>>>> -Matthias
>>>>>
>>>>>
>>>>> [1] https://firebase.google.com/docs/cloud-messaging/admin/errors
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> 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/
>>> 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
>>
>
>
>
> --
> -- Passos
>
> _______________________________________________
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170531/30b85a1d/attachment-0001.html 

From supittma at redhat.com  Wed May 31 05:46:57 2017
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 31 May 2017 05:46:57 -0400
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAAg5f2SJ4tai7GEEn0wyQp9M7jz_9d9xbb_bT+QYnyDE6w8kMw@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
	<CAEQz2CvPa4Q=q+uKh18DP5R1MRAF8YdEBaVNab+bkc7Fox8iPQ@mail.gmail.com>
	<CAAg5f2SJ4tai7GEEn0wyQp9M7jz_9d9xbb_bT+QYnyDE6w8kMw@mail.gmail.com>
Message-ID: <CAEQz2CukbOf5tQtSowMBGW2bRPVp=JXRo=zowY-aWjuzh2CRXw@mail.gmail.com>

On May 30, 2017 3:23 PM, "Matthias Wessendorf" <matzew at apache.org> wrote:



On Tue, May 30, 2017 at 2:06 PM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On Wed, May 24, 2017 at 4:30 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> we do have a problem w/ our current metrics processing. It's complicated
>> (lot'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.
>>
>> I'd like to dramatically simplify our metrics processing... to something
>> like:
>> Success -> could connect to 3rd party, to deliver tokens
>> Failure -> something went wrong when talking to 3rd party service.
>>
>>
>> Right now we do have metrics on push delivery:
>> Pending -> the submission to the 3rd party provider is in flight
>> Success -> we were able to connect, and could deliver *something*
>> Failure -> something obvious, like invalid certificate (APNs), no
>> connection to 3rd party possible, etc
>>
>> 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'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.
>>
>> 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).
>>
>> So, for now, I'd like to dramatically simplify the code, and go with the
>> above Success/Failure solution.
>>
>> 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.
>>
>> This will give us much more freedom and flexibility. Perhaps also, in the
>> future, we want some different stats, and something like Prometheus
>> /Grafana:
>> https://prometheus.io/docs/visualization/grafana/
>>
>> A more flexible system, with independent metrics 'calculation' processing
>> will help us here.
>>
>> Any thoughts?
>>
>>
> What if we remove the current metrics UI
>

For sanity, we are also simplifying the UI:
https://issues.jboss.org/browse/AGPUSH-2090


> and replace them with webhooks that emit events?
>

In the long run, I am open to anything else. I think I mainly care about
the actual push delivery and the events that we will be submitting to a
centralized data hub/pipeline, such as Kafka.

>From there, a consumer process (written in what ever language) can offer
webhooks etc


>   It lets us add events easily, somewhat simplifies debugging, and gives
> integrators a lot more control and hooks into our process.  We can even
> turn the current metrics into a microservice project as an example.
>  (Doubly so when we get Keycloak broken out and properly integrated)
>

the overall idea is to break the server in to a more modular system:
* push-sender.war
* metrics-processor.war (or jar)
* device-regitration.war
* UI process

I think decoupled keycloak would be also key to this, or what do you mean ?

What I meant was it is easier to secure services with a decoupled keycloak.




>
>
>> -Matthias
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> twitter: http://twitter.com/mwessendorfa
>>
>> _______________________________________________
>> 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/
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170531/10b0f24a/attachment.html 

From matzew at apache.org  Wed May 31 10:55:16 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 31 May 2017 16:55:16 +0200
Subject: [aerogear-dev] Simplify the metrics for sanity
In-Reply-To: <CAEQz2CukbOf5tQtSowMBGW2bRPVp=JXRo=zowY-aWjuzh2CRXw@mail.gmail.com>
References: <CAAg5f2ReOu40f9Yq3s3EZDAtZWXLgDV2j_4T4kp=9DA5ps-wkA@mail.gmail.com>
	<CAEQz2CvPa4Q=q+uKh18DP5R1MRAF8YdEBaVNab+bkc7Fox8iPQ@mail.gmail.com>
	<CAAg5f2SJ4tai7GEEn0wyQp9M7jz_9d9xbb_bT+QYnyDE6w8kMw@mail.gmail.com>
	<CAEQz2CukbOf5tQtSowMBGW2bRPVp=JXRo=zowY-aWjuzh2CRXw@mail.gmail.com>
Message-ID: <CAAg5f2TnRQ=xzrXjKeZZ8ZE12UfNS8qa4gLx1zT26xE4M6QtEw@mail.gmail.com>

+9001

On Wed, May 31, 2017 at 11:46 AM, Summers Pittman <supittma at redhat.com>
wrote:

>
>
> On May 30, 2017 3:23 PM, "Matthias Wessendorf" <matzew at apache.org> wrote:
>
>
>
> On Tue, May 30, 2017 at 2:06 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>>
>>
>> On Wed, May 24, 2017 at 4:30 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> we do have a problem w/ our current metrics processing. It's complicated
>>> (lot'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.
>>>
>>> I'd like to dramatically simplify our metrics processing... to something
>>> like:
>>> Success -> could connect to 3rd party, to deliver tokens
>>> Failure -> something went wrong when talking to 3rd party service.
>>>
>>>
>>> Right now we do have metrics on push delivery:
>>> Pending -> the submission to the 3rd party provider is in flight
>>> Success -> we were able to connect, and could deliver *something*
>>> Failure -> something obvious, like invalid certificate (APNs), no
>>> connection to 3rd party possible, etc
>>>
>>> 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'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.
>>>
>>> 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).
>>>
>>> So, for now, I'd like to dramatically simplify the code, and go with the
>>> above Success/Failure solution.
>>>
>>> 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.
>>>
>>> This will give us much more freedom and flexibility. Perhaps also, in
>>> the future, we want some different stats, and something like Prometheus
>>> /Grafana:
>>> https://prometheus.io/docs/visualization/grafana/
>>>
>>> A more flexible system, with independent metrics 'calculation'
>>> processing will help us here.
>>>
>>> Any thoughts?
>>>
>>>
>> What if we remove the current metrics UI
>>
>
> For sanity, we are also simplifying the UI:
> https://issues.jboss.org/browse/AGPUSH-2090
>
>
>> and replace them with webhooks that emit events?
>>
>
> In the long run, I am open to anything else. I think I mainly care about
> the actual push delivery and the events that we will be submitting to a
> centralized data hub/pipeline, such as Kafka.
>
> From there, a consumer process (written in what ever language) can offer
> webhooks etc
>
>
>>   It lets us add events easily, somewhat simplifies debugging, and gives
>> integrators a lot more control and hooks into our process.  We can even
>> turn the current metrics into a microservice project as an example.
>>  (Doubly so when we get Keycloak broken out and properly integrated)
>>
>
> the overall idea is to break the server in to a more modular system:
> * push-sender.war
> * metrics-processor.war (or jar)
> * device-regitration.war
> * UI process
>
> I think decoupled keycloak would be also key to this, or what do you mean
> ?
>
> What I meant was it is easier to secure services with a decoupled
> keycloak.
>
>
>
>
>>
>>
>>> -Matthias
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorfa
>>>
>>> _______________________________________________
>>> 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/
> 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/
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170531/97c9858e/attachment-0001.html