|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
The error indicates that the master is deserializing a response from a slave, and encountered an instance of a class that is originally defined from the master. The remoting library tried to find the classloader that defines this class, by looking up its own export table, but it didn't find it, because apparently it was already unexported.
As can be seen by the stack trace, the deserialization of the response happens in the thread that made the request, and not in the channel reader thread. Thus it seems technically possible that the said classloader was unexported after the response (UserResponse) was received but before it was deserialized by the caller. This is my current hypothesis.
But that implies ClassLoaders getting exported and unexported frequently, and I find that surprising. I'm going to see how classloaders get unexported to see if this hypothesis is likely.
A relevant issue that Jesse points out here is that he observes a number of open tickets in JIRA where Channel.getExportedObject(int) returns null, and that we should be doing better error diagnostics. I need to find where those tickets are.