New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Classloading issues with jboss-marshalling and redisson-tomcat #2984
Comments
Thanks for report! Please try both MarshallingCodecV2 and MarshallingCodec codecs included in attached version. |
Thanks for the quick feedback! Here are the two stack traces,
|
Please try MarshallingCodec with version below. |
I can no longer reproduce the issue using that jar 🎉 |
Fixed |
Expected behavior
When using redisson-tomcat to provide a SessionManager for our tomcat installation, we expect the classloader used to instantiate objects should be the current thread classloader, regardless of which Codec is being used. Using
FSTCodec
this worked as expected. This is to allow the right classloader, Tomcat vs WAR classloader to create the objects which it knows how to create.Actual behavior
After the switch to the
MarshallingCodec
as default we are running into issues with theRiverUnmarshaller
is throwing errors after calling classResolver.resolveClass(). When a thread from my WAR attempts to unmarshall a class it has loaded, for exampleorg.springframework.security.web.savedrequest.DefaultSavedRequest
the classresolver on theRiverUnmarshaller
for some threads points to tomcat’s Classloader (URLClassLoader with apache-tomcat paths)This RiverUnmashaller is a
FastThreadLocal<Unmarshaller> decoderThreadLocal
which is field on theMarshallingCodec
.I can see in the debugger that the MarshallingCodec has classLoader field of my WAR’s class loader, not a reference to tomcat’s. The configuration object on the same MarshallingCodec also points to the WAR class loader.
The number of threads in this broken state where the classloader being used to unmarshall isn't shared by the
MarshallingCodec
seems to change on each run, but reproduced pretty consistently.Steps to reproduce or test case
Running Tomcat
8.5.57.0
, deploy a WAR with a context xml with a manager as described https://github.com/redisson/redisson/tree/master/redisson-tomcat#1-add-redissonsessionmanagerPlace objects onto the session and attempt to retrieve them that are instances of classes not on the tomcat classpath directly (only within the war, spring security for example)
See requests fail sometimes, depending which thread picks up the work.
Redis version
6.0.6
Redisson version
3.13.3
Redisson configuration
The text was updated successfully, but these errors were encountered: