send push notifications to the apps using version "0.14.1", you will receive "TooManyProviderTokenUpdates"

[kangjd81]

I am using pushy library.
The well-used version is "0.13.1"

We upgraded the library version to "0.14.1" and distributed the service.
Perform normal operation without any issues in the initial post-deployment
However, responses to "TooManyProviderTokenUpdates" messages are piling up on the log about "1hour and 40 minutes" later.
Internally, it is expected that a continuous update of the JWT token file will occur at some point.
( Version 0.13.1 does not produce a TooManyProviderTokenUpdates response)

I looked up the 'Apple Developer Forum' on "TooManyProviderTokenUpdates" responses, I checked the token policy below.

The authentication token for the provider is being updated too often.
For security reasons, APNS needs to refresh tokens regularly. Refresh tokens once every 20 to 60 minutes.
APNS rejects all requests that contain timestamps older than 1 hour in the token.
Similarly, if you recreate the token more than once every 20 minutes, the APN reports an error.

My service environment is apps connection from 3 nodes through http proxy server.
One process is generating ApsClient as a singleton pattern.
-- node-1 (one process)
-- node-2 (one process) <-> http proxy <-> APNS
-- node-3 (one process)

CurrentConnection number was given 3.
Below is the ApsClient generation code.

        private volatile static ApnsClient apnsClient;
	static final String keyFilePath = "static/certificate/AuthKey.p8"; 
	static final String keyId="key_id_sample";
	static final String teamId="team_id_sample";
	
	public static ApnsClient getApnsClient(boolean isProduct) {
		
		if(apnsClient == null ){
			synchronized(ApnsConnectManager.class){
				if(apnsClient == null ){
					String appleDestination = isProduct ? ApnsClientBuilder.PRODUCTION_APNS_HOST : ApnsClientBuilder.DEVELOPMENT_APNS_HOST;
					try {
						ApplicationConfig appConfig = PushUtil.getBean(ApplicationConfig.class);
						apnsClient = new ApnsClientBuilder()
						        .setApnsServer(appleDestination)
						        .setConcurrentConnections(3)
						        .setConnectionTimeout(3, TimeUnit.SECONDS)
						        .setSigningKey(ApnsSigningKey.loadFromInputStream(new ClassPathResource(keyFilePath).getInputStream(), teamId, keyId))
						        .setProxyHandlerFactory(new HttpProxyHandlerFactory(new InetSocketAddress(appConfig.getProxyHost(), Integer.parseInt(appConfig.getProxyPort())))) 
						        .build();
					} catch (InvalidKeyException | NoSuchAlgorithmException | IOException e) {
						logger.error(e.getMessage(), e);
						e.printStackTrace();
					}
				}
			}
		}
		return apnsClient;
	}

Push Message lost due to continuous TooManyProviderTokenUpdates response.
As a result, we proceeded with the library rollback. 0.14.1 -> 0.13.1
Does anyone have the same symptoms as me?
What is the cause and what is the problem?

[jchambers]

There have been two major changes to how we handle tokens since 0.13.1:

1. In Proactively rotate authentication tokens before the server complains #747, we started rotating tokens after a fixed amount of time rather than waiting for the server to tell us the token had expired.
2. In Treat token expirations as fatal errors #783, we started closing connections entirely if the server tells us that a token has expired.

It's not clear to me how either of those changes could lead to too many token updates.

I think we're going to need a little more information to understand what's going wrong. Could you try setting the log level for TokenAuthenticationApnsClientHandler to debug? That will tell us how often tokens are changing from Pushy's perspective. We're looking for this line:

pushy/pushy/src/main/java/com/eatthepath/pushy/apns/TokenAuthenticationApnsClientHandler.java

Line 113 in 1639656

log.debug("Proactively expiring authentication token.");

[jchambers]

I'm going to close this issue for now because we don't have enough information to do meaningful debugging. @kangjd81 if you have an opportunity to provide more information, I'll happily reopen the issue. Thanks kindly!