NullPointerException in GrizzlyClientFilter

[pjablonski44]

Hi Team,

We're using Tyrus 1.18 in our project and I've seen in the logs of the application one occurence of following log:

2022-06-29 22:13:11 UTC WARNING GRIZZLY0013: Exception during FilterChain execution
java.lang.NullPointerException
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientFilter.handleRead(GrizzlyClientFilter.java:248)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:95)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:260)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:177)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:109)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:88)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:53)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:515)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:33)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:114)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:569)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:549)
at java.base/java.lang.Thread.run(Thread.java:829)

Looks like the taskProcessor is resolved to null reference here:

It happened once. In the meantime we upgraded to version 1.19 but I can't find any important changes around the failing code between those two versions.
Is it internal issue of the library or could be triggered by wrong configuration?

[jansupol]

I suspect this can happen when WebSocket protocol-related HTTP headers are modified by a user. Do you have any idea what could have caused this? Perhaps ServerEndpointConfig.Configurator#modifyHandshake method could be a candidate for a user code that could lead to this exception.

I am not saying any other cause could have not created this, but it is too difficult to know from the stacktrace only.

[pjablonski44]

Thank you for the comment. I'll double check if we're not doing any modifications to the headers. Now I don't know what could happen this on our end but knowing the possible cause it will be easier to traverse all interactions with Tyrus client to find the root cause.