I've just implemented a lightweight java client for receiving push messages
from AeroGear WebPush Server . It is easy to use and fully async!
A few words about decision to use Jetty as a HTTP/2 client:
Currently there are only 3 Java libraries, which implement client side of
HTTP/2 protocol : Netty, Jetty and OkHttp. I tried all of them:
- First of all I tried to use OkHttp. This is a lightweight http client
for Android and other Java apps. But currently this library supports HTTP/2
protocol only via old HTTP/1.1 API. It works well for simple
request-response, but its client API does not allow to use HTTP/2 features,
like Server Push Frames. I looked at GRPC , because Googlers use OkHttp
for HTTP/2 transport. But they don't use public API, they use only inner
classes to handle frames and built their own logic atop this classes. It
would be too complicated for our purposes.
- Secondary, I tried to refactor our WebPush console to a client
library. But this way is complicated too. netty-codec-http2 does not
provide a client API, it is only codec, low level protocol implementation.
- Now I use jetty-http2-client. It is easy to configure and use, fast
and async. Jetty provides a user friendly API to handle HTTP/2 streams and
get PUSH_PROMISE frames.
For more information, look at my commit history.
In the future, if there will be more lightweight alternatives than Jetty
(for example, new version of OkHttp or Java 9 API), I will rewrite the
transport layer of my library.
Here is an example, how to use my library .
Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy>
GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy>
So I've got a few ideas for how to implement this, but I hope some people
more experienced with the platform can give some feedback before.
In UPS right now we have a concept of categories. A single UPS message can
be broadcast to a bunch of devices which are subscribed to this category.
Google now supports this for GCM on Chrome, iOS, and Android so UPS can
send a single message to GCM and GCM will broadcast that to up to a million
End Quick Background
So first, how do we switch between sending a message to each device in a
category to sending a topic message to GCM?
In TokenLoader.java#L113 we are using the clientInstallationService to
build a string of deviceTokens based on the variant and message criteria.
Is there any reason we can't create a "topicToken" which will be recognized
later by GCMPushNotificationSender? Another benefit to making this change
here is that if we have over a million subscribers to the category we can
just default to the default messaging.
There is also an open issue of whether or not we will update the clients to
filter based on what category a message was sent to. To do this we will
have to include the category information in the message when we send it to
devices going forward. In GCM a topic message includes this information.
This means that if we have over a million subscriptions in the topic we
will need to fall back to using the category information anyway.
Continuing on from the thread of falling back, it is possible for a topic
message to fail to send because there are too many subscribers. How would
UPS handle regenerating the messages as deviceToken instead of topicToken
Of course if someone has a better idea than "topicTokens" I'm all ears.
so as outlined in previous thread , I have prototyped a JMS batching
approach for push message delivery.
We've discussed the approach with Matthias, Mirek Novak and Ondrej
Chaloupka (EAP QE & JMS/JTA experts, thank you guys!) and these documents
describes a concept that we have came with:
Implementation-wise, I've so far prototyped the messaging part (split
SenderService functionality to two subsequent queues with MDBs as shown on
but that's just a start, since we must configure it appropriately for
efficiency (queue configuration and batch sizes) and verify that
configuration works as expected,
the prototype lives on a branch (unpolished, to be squashed later):
Off course, you can play with it already. :-)
Apart from the new requirement of using Java EE full profile (JMS), the
prototype leverages implementation-specific configurations and APIs:
- org.hibernate.Query for token streaming / batch fetching
- HornetQ configurations of queue size, blocking behavior and message
That pretty much binds us to WildFly/EAP - we can tweak it to run on any
compliant app server, but without specific configurations it won't work
Once configured and functionally tested (that can even wait for Beta2 I
we can cooperate with Mobile QE on testing (Stefan, Adam), their test suite
contains mocks of APNS/GCM against which we can load test.
Good morning, today we have our OTP demos pointing to guess what, or good
and old AeroGear Controller. I would like to move all the demos and the
backend for the cookbooks to Keycloak 1.5.
"The measure of a man is what he does with power" - Plato
Volenti Nihil Difficile
we try to deploy auth and agpush .war files on Weblogic server.
We have problem with persistence provider. We add
to persistence.xml in model-jpa but also we have problem with auth.
It is possible to set explicitly the persistence provider in Auth project?
So the current PRs for Topics use them automatically when you subscribe to
a category. Google doesn't support delivering messages to a subset of
users over a topic. UPS has the ability to deliver messages to subsets of
category subscribers (via alias and deviceType).
I think that a suitable workaround for this would be if a message is sent
to a category, and there is a topic available, AND the message isn't
filtered based on alias or deviceType then use the topic. Otherwise the
message should be treated "normally" and use registrationId based sending
(like we do now).
And as an aside, can you guys think of other use cases where the all or
nothing nature of topics might be a problem?