java.lang.classcastexception weblogic

Oracle Weblogic Server

If you find below ClassCast error in logs and the server goes down or becomes unresponsive to some modules or on whole you can try below steps to stop the issue from reoccuring.

####<JUn 21, 2012 10:52:51 AM EDT> <Error> <Kernel>
<shheb.local.new.com> <wls-m01> <ACTIVE
ExecuteThread: ‘1’ for queue: ‘weblogic.kernel.Default (self-tuning)’>
<<WLS Kernel>> <1367765571206> <BEA-000802> <ExecuteRequest failed
java.lang.ClassCastException: weblogic.jms.frontend.FEConnectionFactoryImpl.
java.lang.ClassCastException: weblogic.jms.frontend.FEConnectionFactoryImpl
at
weblogic.rmi.cluster.BasicReplicaHandler.refreshReplicaList(BasicReplicaHandler.java:519)
at
weblogic.rmi.cluster.BasicReplicaHandler.failOver(BasicReplicaHandler.java:211)
at
weblogic.rmi.cluster.ClusterableRemoteRef.handleException(ClusterableRemoteRef.java:304)
at
weblogic.rmi.cluster.ClusterableRemoteRef.invoke(ClusterableRemoteRef.java:275)
at
weblogic.jms.frontend.FEConnectionFactoryImpl_1211_WLStub.connectionCreateRequest(Unknown
Source)
at
weblogic.jms.client.JMSConnectionFactory.setupJMSConnection(JMSConnectionFactory.java:224)
at
weblogic.jms.client.JMSConnection.preCreateReplacement(JMSConnection.java:1736)
at weblogic.jms.client.JMSConnection.reconnect(JMSConnection.java:2515)
at
weblogic.jms.client.WLConnectionImpl.processReconnectTimer(WLConnectionImpl.java:253)
at weblogic.jms.client.JMSConnection.timerExpired(JMSConnection.java:1347)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:293)
at
weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

When we checked the error number seen it had no info on how to solve it.

BEA-000802
Error: ExecuteRequest failed\n t.
Description: Server t was shutdown unintentionally.
Cause : An execute request threw an exception that was not handled.
So after searching through Oracle docs and after trying multiple ways to configure JMS we found out that, this error comes in logs when there is improper file store and JMS server targeting configurations done.

Basically this issue is noticed when the target JMS servers and file stores are non-migratable. When we targeted to migratable servers this error goes away, not sure if it’s an bug or not but it works.

Below are few Targeting Best Practices For JMS resources from Oracle : More references can be found at the bottom of the article:

Use the following steps to configure JMS servers and persistent stores:

Create a custom store on each WebLogic server that will host a JMS server. If there’s already a custom store on a WebLogic server, you can skip this step as its usually more convenient and more performant for services to share a store. (Why use a custom store? Custom stores provide more flexibility in tuning and administration. In addition, the default file store is not migratable — only custom stores are migratable.)

In a cluster, target each store to its host server’s “default migratable target”. If you have decided not to use a cluster, target each store directly to its host server. Migratable targets enable restart-in-place options on a store failure, and also enable service migration options.

It is recommended to always target to migratable targets when available (instead of direct server targets). Migratable targets are compatible with the whole server migration option, and usually should be configured even when whole server migration is the primary fail-over option.

Configure a JMS server on each WebLogic server. Configure the JMS server to reference the store that was created in 1st step. Target the JMS server to the same target that was used for the store. Multiple JMS servers can reference the same store.

Configure message count quotas on each JMS server. There is no default quota, so configuring one helps protect against out-of-memory conditions. Rule of thumb: conservatively assume that each message consumes 512 bytes of memory even if it is paged out.

Although JMS paging is enabled by default, verify that the default behavior is valid for your environment.
So to fix the above error vi config.xml file and update the following.

Sample configuration Where JMS and File Store Targeted To Migratable servers:

<jms-server>
<name>base1JmsServer</name>
<target>biotech_server1 (migratable)</target>
<persistent-store>BIOJMSStore</persistent-store>
</jms-server>
<jms-server>
<name>base1JmsServer2</name>
<target>biotech_server2 (migratable)</target>
<persistent-store>BIOJMSStore2</persistent-store>
</jms-server>
<jms-server>
<name>base1JmsServer3</name>
<target>biotech_server3 (migratable)</target>
<persistent-store>BIOJMSStore3</persistent-store>
</jms-server>
<migratable-target>
<name>biotech_server1 (migratable)</name>
<notes>This is a system generated default migratable target for a server.Do not delete manually.</notes>
<user-preferred-server>biotech_server1</user-preferred-server>
<constrained-candidate-server></constrained-candidate-server>
<cluster>SuperBIO_cluster</cluster>
</migratable-target>
<migratable-target>
<name>biotech_server2 (migratable)</name>
<notes>This is a system generated default migratable target for a server.Do not delete manually.</notes>
<user-preferred-server>biotech_server2</user-preferred-server>
<constrained-candidate-server></constrained-candidate-server>
<cluster>SuperBIO_cluster</cluster>
</migratable-target>
<migratable-target>
<name>biotech_server3 (migratable)</name>
<notes>This is a system generated default migratable target for a server.Do not delete manually.</notes>
<user-preferred-server>biotech_server3</user-preferred-server>
<constrained-candidate-server></constrained-candidate-server>
<cluster>SuperBIO_cluster</cluster>
</migratable-target>

After the above change you need to bounce the server and check logs.

It is recommended by Oracle to always target to migratable targets when available (instead of direct server targets). Migratable targets are compatible with the whole server migration option, and usually should be configured even when whole server migration is the primary fail-over option.
More on Best practices Can be found here:

http://docs.oracle.com/cd/E17904_01/web.1111/e13738/best_practice.htm

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.

Leave a Reply