Token is expired

Question

Token is expired

Dilip Dhankecha 5

As part of our Spring Boot 3.1.2 setup, we have configured a JMSListener to receive messages from the service bus via Spring Boot. The system worked as expected up until today, but today we are facing this issue that I have linked below.

org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing	
      at org.springframework.jms.support.JmsUtils.convertJmsAccessException(JmsUtils.java:311) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.support.JmsAccessor.convertJmsAccessException(JmsAccessor.java:184) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:510) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:587) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:664) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at com.cofinity.gr.orchestration.azure.servicebus.AzureServiceBusProvider.publishMessage(AzureServiceBusProvider.java:34) ~[classes!/:0.0.1-SNAPSHOT]	
      at com.cofinity.gr.orchestration.azure.servicebus.AzureServiceBusProvider.publishMessage(AzureServiceBusProvider.java:27) ~[classes!/:0.0.1-SNAPSHOT]	
      at com.cofinity.gr.orchestration.service.RawDataService.publishErrorMessage(RawDataService.java:1148) ~[classes!/:0.0.1-SNAPSHOT]	
      at com.cofinity.gr.orchestration.service.RawDataService.processToGenerateBpnV1(RawDataService.java:404) ~[classes!/:0.0.1-SNAPSHOT]	
      at jdk.internal.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) ~[na:na]	
      at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[na:na]	
      at java.base/java.lang.reflect.Method.invoke(Unknown Source) ~[na:na]	
      at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343) ~[spring-aop-6.0.11.jar!/:6.0.11]	
      at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:704) ~[spring-aop-6.0.11.jar!/:6.0.11]	
      at com.cofinity.gr.orchestration.service.RawDataService$$SpringCGLIB$$0.processToGenerateBpnV1(<generated>) ~[classes!/:0.0.1-SNAPSHOT]	
      at com.cofinity.gr.orchestration.tamr.process.BPNGenerationProcessor.lambda$initProcess$0(BPNGenerationProcessor.java:54) ~[classes!/:0.0.1-SNAPSHOT]	
      at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(Unknown Source) ~[na:na]	
      at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source) ~[na:na]	
      at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source) ~[na:na]	
      at java.base/java.util.stream.ForEachOps$ForEachTask.compute(Unknown Source) ~[na:na]	
      at java.base/java.util.concurrent.CountedCompleter.exec(Unknown Source) ~[na:na]	
      at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source) ~[na:na]	
      at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source) ~[na:na]	
      at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source) ~[na:na]	
      at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source) ~[na:na]	
      at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source) ~[na:na]


Caused by: jakarta.jms.JMSException: ExpiredToken: The token is expired. TrackingId:edf8ecf6-53d2-4f47-97aa-f95597712518_G35, SystemTracker:NoSystemTracker, Timestamp:2023-12-11T09:55:11 TrackingId:e7d30ca046d84fc28c69cf0c5cfcc265_G35, SystemTracker:gateway7, Timestamp:2023-12-11T09:55:11 [condition = com.microsoft:auth-failed]	
      at org.apache.qpid.jms.provider.ProviderException.toJMSException(ProviderException.java:34) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.JmsConnection.send(JmsConnection.java:778) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.JmsNoTxTransactionContext.send(JmsNoTxTransactionContext.java:37) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.JmsSession.send(JmsSession.java:976) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.JmsSession.send(JmsSession.java:855) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.JmsMessageProducer.sendMessage(JmsMessageProducer.java:252) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.JmsMessageProducer.send(JmsMessageProducer.java:200) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.messaginghub.pooled.jms.JmsPoolMessageProducer.sendMessage(JmsPoolMessageProducer.java:194) ~[pooled-jms-3.1.0.jar!/:na]	
      at org.messaginghub.pooled.jms.JmsPoolMessageProducer.send(JmsPoolMessageProducer.java:88) ~[pooled-jms-3.1.0.jar!/:na]	
      at org.messaginghub.pooled.jms.JmsPoolMessageProducer.send(JmsPoolMessageProducer.java:77) ~[pooled-jms-3.1.0.jar!/:na]	
      at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:637) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:611) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.core.JmsTemplate.lambda$send$3(JmsTemplate.java:589) ~[spring-jms-6.0.11.jar!/:6.0.11]	
      at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:507) ~[spring-jms-6.0.11.jar!/:6.0.11]	... 23 common frames omitted

Caused by: org.apache.qpid.jms.provider.ProviderException: ExpiredToken: The token is expired. TrackingId:edf8ecf6-53d2-4f47-97aa-f95597712518_G35, SystemTracker:NoSystemTracker, Timestamp:2023-12-11T09:55:11 TrackingId:e7d30ca046d84fc28c69cf0c5cfcc265_G35, SystemTracker:gateway7, Timestamp:2023-12-11T09:55:11 [condition = com.microsoft:auth-failed]	
      at org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToNonFatalException(AmqpSupport.java:181) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.provider.amqp.builders.AmqpResourceBuilder.getOpenAbortExceptionFromRemote(AmqpResourceBuilder.java:305) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.provider.amqp.builders.AmqpResourceBuilder.handleClosed(AmqpResourceBuilder.java:191) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.provider.amqp.builders.AmqpResourceBuilder.processRemoteClose(AmqpResourceBuilder.java:132) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:992) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.provider.amqp.AmqpProvider.onData(AmqpProvider.java:878) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.transports.netty.NettyTcpTransport$NettyTcpTransportHandler.channelRead0(NettyTcpTransport.java:548) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at org.apache.qpid.jms.transports.netty.NettyTcpTransport$NettyTcpTransportHandler.channelRead0(NettyTcpTransport.java:541) ~[qpid-jms-client-2.0.0.jar!/:na]	
      at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1383) ~[netty-handler-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1246) ~[netty-handler-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1295) ~[netty-handler-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:529) ~[netty-codec-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:468) ~[netty-codec-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:290) ~[netty-codec-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:800) ~[netty-transport-classes-epoll-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:499) ~[netty-transport-classes-epoll-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:397) ~[netty-transport-classes-epoll-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.94.Final.jar!/:4.1.94.Final]	
      at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.94.Final.jar!/:4.1.94.Final]	
      at java.base/java.lang.Thread.run(Unknown Source) ~[na:na]

Could anyone shed some light on this issue?

Dilip Dhankecha 5 Reputation points

2023-12-12T05:16:36.7533333+00:00

@MuthuKumaranMurugaachari-MSFT
My thanks go to you for your response.
The entire process here has been handled by the Azure server itself. During a long operation, we face this issue during the process. After a few minutes, JMS will again generate the token for the provider and message publishing will resume.
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-12-12T15:21:44.05+00:00

Dilip Dhankecha If the tokens are generated by a SDK using connection string, then SDK takes care of renewing the tokens before it expires. However, there might be a scenario where it would get expired during the long running operations and you will observe those expired token errors. This is expected and as you described, this should succeed on retry operations (no action needed).

I hope this helps and let me know if any questions.
Dilip Dhankecha 5 Reputation points

2023-12-12T16:10:28.9566667+00:00

@MuthuKumaranMurugaachari-MSFT
Do you have an idea For example, when we are running with a long operation then we receive a token expiration error but do we need to persist the message again or does the SDK manage it?
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-12-13T14:20:30.4533333+00:00

Dilip Dhankecha This depends on SDK you are using. If you use Jakarta Messaging (based on stack trace), I suggest reviewing https://github.com/jakartaee/messaging doc for the behavior.
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-12-15T14:47:55.13+00:00

Dilip Dhankecha If you have any other questions, feel free to reach out to me and am happy to answer. Posting the comment to benefit others in the community.

1 answer

Your answer

Dilip Dhankecha 5 Reputation points

2023-12-12T05:16:36.7533333+00:00

@MuthuKumaranMurugaachari-MSFT
My thanks go to you for your response.
The entire process here has been handled by the Azure server itself. During a long operation, we face this issue during the process. After a few minutes, JMS will again generate the token for the provider and message publishing will resume.
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-12-12T15:21:44.05+00:00

Dilip Dhankecha If the tokens are generated by a SDK using connection string, then SDK takes care of renewing the tokens before it expires. However, there might be a scenario where it would get expired during the long running operations and you will observe those expired token errors. This is expected and as you described, this should succeed on retry operations (no action needed).

I hope this helps and let me know if any questions.
Dilip Dhankecha 5 Reputation points

2023-12-12T16:10:28.9566667+00:00

@MuthuKumaranMurugaachari-MSFT
Do you have an idea For example, when we are running with a long operation then we receive a token expiration error but do we need to persist the message again or does the SDK manage it?
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-12-13T14:20:30.4533333+00:00

Dilip Dhankecha This depends on SDK you are using. If you use Jakarta Messaging (based on stack trace), I suggest reviewing https://github.com/jakartaee/messaging doc for the behavior.
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-12-15T14:47:55.13+00:00

Dilip Dhankecha If you have any other questions, feel free to reach out to me and am happy to answer. Posting the comment to benefit others in the community.

Answer 1

Dilip Dhankecha Thanks for posting your question in Microsoft Q&A. As error message: ExpiredToken: The token is expired states, the token is expired and request you to validate the connection string in the azure portal. This issue might also occur if there is clock skew issue on the client machine/VM and there is a similar discussion in this thread. Try validating that and see if it helps.

Also, if tokens are generated by SDK using connection string, then SDK takes care of renewing the tokens before it expires. However, there might be a scenario where it would get expired during the long running operations and you will observe those expired token errors. This is expected and as you described, this should succeed on retry operations (no action needed).

If you found the answer to your question helpful, please take a moment to mark it as Yes for others to benefit from your experience. Or simply add a comment tagging me and would be happy to answer your questions.

Share via

Token is expired

1 answer

Your answer