[
https://issues.apache.org/jira/browse/AMQ-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Calvin Moody updated AMQ-4746:
------------------------------
Description:
Applets fail to deserailize messages in a timely manner after a network failure
triggers a reconnect using the FailoverTransport
In ClassLoadingAwareObjectInputStream.java the load() method makes a call to
Class.forName().
For the primitive types (int, boolean, etc.) this would result in a call
similar to:
Class.forName("int", false, loader); //Where loader is the
Applet2ClassLoader
Since Applet2ClassLoader is a URLClassLoader and "int.class" is not in the jar
cache it pulled down from the server at the start of application, it is going
to try and go to the server to resolve this class.
In the event of a network failure, this will result in the ClassLoader having
to wait for the socket timeout. (see stacktrace at link) Once this socket
timeout occurs, the load() method then attempts to lookup the class in the
primitive HashMap that is statically initialized. This returns the class for
the int and the deserialization continues on.
At first it seemed like the messages were failing to be received but it turned
out they were just taking a very long time to be deserialized. This problem can
be avoided by changing the order in which ClassLoadingAwareObjectInputStream
tries to resolve the class.
Here is the change I made to the load() method:
http://activemq.2283324.n4.nabble.com/Applet-Class-Loader-Problems-td4671835.html
was:
In ClassLoadingAwareObjectInputStream.java the load() method makes a call to
Class.forName().
For the primitive types (int, boolean, etc.) this would result in a call
similar to:
Class.forName("int", false, loader); //Where loader is the
Applet2ClassLoader
Since Applet2ClassLoader is a URLClassLoader and "int.class" is not in the jar
cache it pulled down from the server at the start of application, it is going
to try and go to the server to resolve this class.
In the event of a network failure, this will result in the ClassLoader having
to wait for the socket timeout. (see stacktrace at link) Once this socket
timeout occurs, the load() method then attempts to lookup the class in the
primitive HashMap that is statically initialized. This returns the class for
the int and the deserialization continues on.
At first it seemed like the messages were failing to be received but it turned
out they were just taking a very long time to be deserialized. This problem can
be avoided by changing the order in which ClassLoadingAwareObjectInputStream
tries to resolve the class.
Here is the change I made to the load() method:
http://activemq.2283324.n4.nabble.com/Applet-Class-Loader-Problems-td4671835.html
> Applet ClassLoader Problems
> ---------------------------
>
> Key: AMQ-4746
> URL: https://issues.apache.org/jira/browse/AMQ-4746
> Project: ActiveMQ
> Issue Type: Bug
> Components: JMS client
> Affects Versions: 5.7.0, 5.8.0
> Environment: Windows 7, Java 1.7 or 1.6, Applet
> Reporter: Calvin Moody
> Labels: ClassLoader
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Applets fail to deserailize messages in a timely manner after a network
> failure triggers a reconnect using the FailoverTransport
> In ClassLoadingAwareObjectInputStream.java the load() method makes a call to
> Class.forName().
> For the primitive types (int, boolean, etc.) this would result in a call
> similar to:
> Class.forName("int", false, loader); //Where loader is the
> Applet2ClassLoader
> Since Applet2ClassLoader is a URLClassLoader and "int.class" is not in the
> jar cache it pulled down from the server at the start of application, it is
> going to try and go to the server to resolve this class.
> In the event of a network failure, this will result in the ClassLoader having
> to wait for the socket timeout. (see stacktrace at link) Once this socket
> timeout occurs, the load() method then attempts to lookup the class in the
> primitive HashMap that is statically initialized. This returns the class for
> the int and the deserialization continues on.
> At first it seemed like the messages were failing to be received but it
> turned out they were just taking a very long time to be deserialized. This
> problem can be avoided by changing the order in which
> ClassLoadingAwareObjectInputStream tries to resolve the class.
> Here is the change I made to the load() method:
> http://activemq.2283324.n4.nabble.com/Applet-Class-Loader-Problems-td4671835.html
>
--
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
