4:28 p.m.
JBoss 4.2.1.GA (which includes jboss-remoting 2.2.1.GA)
Using EJB3 with ClassLoader isolation and Call-By-Value
We have two ears (A, B) running in the same jboss, which each make a call to a third ear
(C), deployed in a second jboss, to retrieve data objects. The class definitions for the
data objects are contained in a shared jar file that each ear has in its "lib"
directory.
When A and B both make a call to C at the same time, one of the ears will usually receive
a ClassCastException since the data objects that are returned are in the other ear's
ClassLoader. Additionally, once this problem occurs, it will continue to occur until the
jboss instance is restarted.
We have made a code change in MicroRemoteClientInvoker, which has almost completely
eliminated the ClassCastException. In the few cases where it does still occur, it
doesn't cause the jboss to get into the state where it keeps on occurring, so it seems
that there is still a problem beyond the below code change.
MicroRemoteClientInvoker's invoke(InvocationRequest invocationReq) method is, in part,
the following in jboss-remoting 2.2.1.GA [and seemingly unchanged in newer versions]:
| UnMarshaller unmarshaller = getUnMarshaller();
|
| // ...marshaller code removed...
|
| if (unmarshaller == null)
| {
| // creating a new classloader containing the remoting class loader (for
remote classloading)
| // and the current thread's class loader. This allows to load remoting
classes as well as
| // user's classes.
| ClassLoader remotingClassLoader =
| new RemotingClassLoader(getClassLoader(),
Thread.currentThread().getContextClassLoader());
|
| // try by locator (in case unmarshaller class name specified)
| unmarshaller = MarshalFactory.getUnMarshaller(getLocator(),
getClassLoader());
| if (unmarshaller == null)
| {
| unmarshaller = MarshalFactory.getUnMarshaller(getDataType(),
getSerializationType());
| if (unmarshaller == null)
| {
| // went as far as possible to find a unmarshaller, will have to give
up
| throw new InvalidMarshallingResource(
| "Can not find a valid unmarshaller for data type: " +
getDataType());
| }
| setUnMarshaller(unmarshaller);
| }
| unmarshaller.setClassLoader(remotingClassLoader);
| }
|
I see two potential problems:
1) The member variable for the unmarshaller gets set by
"setUnMarshaller(unmarshaller);". However, it seems that multiple ears can be
using the same instance of the MicroRemoteClientInvoker, so, either there should be no
member variable for the unmarshaller (i.e. it should be kept local to the invoke method)
or multiple ears shouldn't be using the same MicroRemoteClientInvoker.
2) MarshalFactory doesn't seem to have any synchronization. I didn't spend much
time trying to see if there is a specific problem with the lack of synchronization, but I
did synchronize around the entire unmarshaller conditional on the MarshalFactory.class.
The timing that seems to have been causing the problem is:
<Call1 and Call2 are each from different ears/ClassLoaders in the same jboss instance.
They are both calls to a service in a different jboss.>
t=0; Call1 gets the local unmarshaller which is null
t=1; Call1 goes into the code above, gets the unmarshaller, and sets the member variable
with "setUnMarshaller(unmarshaller)"
t=2; Call2 gets the local unmarshaller which is now the same as what Call1 got
t=3; Call2 does not go into the above conditional since the unmarshaller is not null, so
it doesn't call "unmarshaller.setClassLoader(remotingClassLoader);" (*!which
means it is using the same classloader as Call1!*)
t=4; a ClassCastException follows
The modified code which is working for us is below. The entire conditional synchronizes
on MarshalFactory.class (which may not be neccessary) and the
"setUnMarshaller(unmarshaller)" is commented out (which keeps the unmarshaller
member variable null, so all calls to invoke get the proper unmarshaller and set it with
the proper ClassLoader).
| synchronized (MarshalFactory.class) {
| if (unmarshaller == null)
| {
| // creating a new classloader containing the remoting class loader (for
remote classloading)
| // and the current thread's class loader. This allows to load
remoting classes as well as
| // user's classes.
| ClassLoader remotingClassLoader =
| new RemotingClassLoader(getClassLoader(),
Thread.currentThread().getContextClassLoader());
|
| // try by locator (in case unmarshaller class name specified)
| unmarshaller = MarshalFactory.getUnMarshaller(getLocator(),
getClassLoader());
| if (unmarshaller == null)
| {
| unmarshaller = MarshalFactory.getUnMarshaller(getDataType(),
getSerializationType());
| if (unmarshaller == null)
| {
| // went as far as possible to find a unmarshaller, will have to give
up
| throw new InvalidMarshallingResource(
| "Can not find a valid unmarshaller for data type: " +
getDataType());
| }
| //setUnMarshaller(unmarshaller);
| }
| unmarshaller.setClassLoader(remotingClassLoader);
| }
| }
|
I apologize for not having a test case ready, but we're still trying to get everything
fully tested and stable in production now that we have the above code changes. Please let
us know if any additional information is required. Any help is appreciated.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4126367#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...