Assertion error when closing QueueReceiver

Question

Hi,
I initially posted this in the JMS newsgroup, but got the following response
from Zach:
This appears to a be a problem with class loaders and/or RMI,
that is to say it is not a JMS Problem. Specifically, the assertion
is ensuring that the thread has a class loader - and your thread does
not. The same check was in place for 6.0 so I am not sure why it
fails now on 6.1
Please post this in the rmi-iiop newsgroup.So here goes. One additional comment: when switching from WL 6.0 to 6.1, we
were able to improve the packaging of the application. With 6.0, we were
forced to make some of the classes available in the server's system
classpath. With 6.1, the application is now in an EAR file and uses a
Classpath: entry in the manifest file for referencing a utility package
(dc.jar). On the client side, the classpath contains weblogic.jar + the same
dc.jar file + another jar file containing various serializable classes
(value objects), JavaBeans etc that are necessary because we are passing
serialized objects as JMS messages.
Here is the original problem description:
We have a problem on WL6.1 with an application that used to work fine on WL
6.0 SP2. We have a JMS queue in the server, and a client process connects to
this queue. The application works fine, i.e. the client can both send and
receive messages on the queue without any problem. However, when the client
disconnects through the following bit of code:
public void stop() throws TransportException {
synchronized (jmsSync) {
try {
receiver.close();
session.close();
connection.close();
} catch (Exception e) {
throw new TransportException(e);
WL throws an AssertionError - see full trace below.
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Assertion
violated ]
at weblogic.utils.Debug.assert(Debug.java:74)
at weblogic.j2ee.ApplicationManager.loadClass(ApplicationManager.java:107)
at
weblogic.rjvm.MsgAbbrevInputStream.readClassDescriptor(MsgAbbrevInputStream.
java:211)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectIn
putStream.java:83)
at
weblogic.common.internal.ChunkedObjectInputStream.readObject(ChunkedObjectIn
putStream.java:115)
at weblogic.rmi.internal.ObjectIO.readObject(ObjectIO.java:56)
at
weblogic.rmi.internal.BasicRemoteRef.unmarshalReturn(BasicRemoteRef.java:230
at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:134)
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35)
at $Proxy2.dispatchSyncNoTranFuture(Unknown Source)
at
weblogic.jms.dispatcher.DispatcherWrapperState.dispatchSyncNoTran(Dispatcher
WrapperState.java:341)
at weblogic.jms.client.JMSSession.consumerClose(JMSSession.java:1331)
at weblogic.jms.client.JMSConsumer.close(JMSConsumer.java:329)
at ubiquity.dc.JMSComputer.stop(JMSComputer.java:112)
at ubiquity.rapids.matlab.Engine.stop(Engine.java:57)
at ubiquity.rapids.matlab.Engine.stopApplication(Engine.java:371)
--------------- nested within: ------------------
weblogic.rmi.extensions.RemoteRuntimeException - with nested exception:
[weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Assertion
violated ]]
at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:60)
at $Proxy2.dispatchSyncNoTranFuture(Unknown Source)
at
weblogic.jms.dispatcher.DispatcherWrapperState.dispatchSyncNoTran(Dispatcher
WrapperState.java:341)
at weblogic.jms.client.JMSSession.consumerClose(JMSSession.java:1331)
at weblogic.jms.client.JMSConsumer.close(JMSConsumer.java:329)
at ubiquity.dc.JMSComputer.stop(JMSComputer.java:112)
at ubiquity.rapids.matlab.Engine.stop(Engine.java:57)
at ubiquity.rapids.matlab.Engine.stopApplication(Engine.java:371)
Thanks,
Alain.
Alain Rogister
http://www.ubiquity.be

Answer 1

Zach,
I checked this and the classloader is null, so this must be the cause of the
problem. Note that our JMS client app is installed as a W2K service. The
software we use registers the service with a set of parameters like this:
RapidsEngines.exe -install %1
%JAVA_HOME%\jre\bin\hotspot\jvm.dll -Djava.class.path=%ENGINE_CLASSPATH% -st
art ubiquity.rapids.matlab.Engine -stop
ubiquity.rapids.matlab.Engine -method stopApplication -out
%LOG_PATH%\stdout.log -err %LOG_PATH%\stderr.log
This means that, on the Engine class, the static main() method will be
called by the start event on the service (this is the default if no other
method is specified), and the stopApplication() static method will be called
by the stop event on the service. For some reason that I don't understand
yet, the ContextClassLoader is null at this point. Anyway, I guess if the
client connection to WL is just terminated without closing JMS resources
properly, WL will do the cleanup at some point.
Should I file a bug report anyway regarding the AssertionError that gets
thrown ?
Cheers,
Alain.
Alain Rogister
http://www.ubiquity.be
"Zach" <[email protected]> wrote in message
news:[email protected]..
Also, is this the bottom of the stack? Do you have a class loader
at the following place in the stack trace?
at ubiquity.dc.JMSComputer.stop(JMSComputer.java:112)
at ubiquity.rapids.matlab.Engine.stop(Engine.java:57)
at ubiquity.rapids.matlab.Engine.stopApplication(Engine.java:371)
if (Thread.getContextClassLoader() == null) {
System.out.println("DANGER WILL ROBINSON");
_sjz.