You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've started using pushy. I must say, a nice and fast library. We are running it on Wildfly 22, using pushy com.eatthepath:pushy:0.15.4.
We see logs like these when it works:
Wrote payload on stream 45: <json message pushed>
and our ApnsClientMetricsListener.handleNotificationSent() gets invoked.
When the problem occurs these messages are no longer seen in the log and handleNotificationSent() isn't invoked, and but I can still see from other logs that we post message to pushy. We also never get callbacks in .whenCompleted() when the problem is there. When I investigate a heap-dump I can see 100-thousand of SimpleApnsPushNotification-messages in the ApnsChannelPool (or rather an anonymous subclass), indicating that it stopped processing them.
In wildfly it should be enough to restart a module to get it working again, unless either all the threads are busy (forever), or something is not being restarting when wildfly service is restarted. When it hung, I tried changing from using a wildfly ManagedExecutorService to the default pushy and that didn't make start processing messages unless I restarted the entire container.. This indicates to me pushy/netty is doing some deep stuff that's probably not legal wildfly. I have not disabled the unsafe api's yet, via JVM arguments.
Note that nothing else in our container is using this particular ManagedExecutorService which we have given to ApnsClient.
I noticed here that other's are using pushy on wildfly with apparent success, according to other old closed issues.
When we saw the problem in prod we didn't close the connection, and created unreasonably many apns'clients. I have seen it once again in test where we only create one ApnsClient in a @Singleton bean and closes it on shutdown, so I don't think that was the problem.
Any thoughts?
I have attached the full java file (renamed to txt), here's an abbreviated version with the most essential parts:
We've started using pushy. I must say, a nice and fast library. We are running it on Wildfly 22, using pushy
com.eatthepath:pushy:0.15.4
.We see logs like these when it works:
and our
ApnsClientMetricsListener.handleNotificationSent()
gets invoked.When the problem occurs these messages are no longer seen in the log and
handleNotificationSent()
isn't invoked, and but I can still see from other logs that we post message to pushy. We also never get callbacks in.whenCompleted()
when the problem is there. When I investigate a heap-dump I can see 100-thousand ofSimpleApnsPushNotification
-messages in theApnsChannelPool
(or rather an anonymous subclass), indicating that it stopped processing them.In wildfly it should be enough to restart a module to get it working again, unless either all the threads are busy (forever), or something is not being restarting when wildfly service is restarted. When it hung, I tried changing from using a wildfly ManagedExecutorService to the default pushy and that didn't make start processing messages unless I restarted the entire container.. This indicates to me pushy/netty is doing some deep stuff that's probably not legal wildfly. I have not disabled the unsafe api's yet, via JVM arguments.
Note that nothing else in our container is using this particular ManagedExecutorService which we have given to ApnsClient.
I noticed here that other's are using pushy on wildfly with apparent success, according to other old closed issues.
When we saw the problem in prod we didn't close the connection, and created unreasonably many apns'clients. I have seen it once again in test where we only create one
ApnsClient
in a@Singleton
bean and closes it on shutdown, so I don't think that was the problem.Any thoughts?
I have attached the full java file (renamed to txt), here's an abbreviated version with the most essential parts:
Related but unimportant, I enabled the logging like this in log4j:
CloudPushAppleService.java.txt
The text was updated successfully, but these errors were encountered: