Deadlock in TopLink when using JMS listener on WebLogic

I am experiencing a deadlock in TopLink 10.1.3 on WebLogic 9 in code that previously worked on TopLink 9.0.4 with WebLogic 8.1. As such, I'm not sure if it's due to the TopLink change, the WebLogic change or both. Anyway, we have a JMS listener (note, NOT a MessageDrivenBean) that is updating an existing TopLink cached domaing object. The JMS listener thread gets stuck when attempting to commit the transaction. The thread-dump shows that there is another thread which is blocked in the ConcurrencyManager waiting to obtain the lock on an object which is being updated by the listener thread. It appears to me that the root cause is that the Synchronization.afterCompletion() listener is running on a different thread than the one which owns the locks which were obtained beforeCompletion.
See stack traces.
First, the message listener thread which is waiting for participants in the transaction to commit:
"[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=9 tid=0x3a4a4728 nid=0xa48 in Object.wait() [0x3a0cf000..0x3a0cfbec]
     at java.lang.Object.wait(Native Method)
     - waiting on <0x0c7a0908> (a weblogic.transaction.internal.ServerTransactionImpl)
     at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:2665)
     - locked <0x0c7a0908> (a weblogic.transaction.internal.ServerTransactionImpl)
     at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:2570)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:277)
     at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:226)
     at weblogic.ejb.container.internal.BaseEJBObject.postInvoke1(BaseEJBObject.java:539)
     at weblogic.ejb.container.internal.StatelessEJBObject.postInvoke1(StatelessEJBObject.java:72)
     at weblogic.ejb.container.internal.BaseEJBObject.postInvokeTxRetry(BaseEJBObject.java:374)
     at com.avinamart.BusinessLogic.Bean.JobService.JobService_u1ylwo_EOImpl.submitJobAndRun(JobService_u1ylwo_EOImpl.java:1388)
     at com.avinamart.Framework.Event.Task.OptimizationTaskListener._submitAsAJob(OptimizationTaskListener.java:253)
     at com.avinamart.Framework.Event.Task.OptimizationTaskListener._submitAsAJob(OptimizationTaskListener.java:217)
     at com.avinamart.Framework.Event.Task.OptimizationTaskListener.processMessage(OptimizationTaskListener.java:344)
     at com.emptoris.base.event.EPASSMessageBaseListener.onMessage(EPASSMessageBaseListener.java:722)
     at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:3824)
     at weblogic.jms.client.JMSSession.execute(JMSSession.java:3738)
     at weblogic.jms.client.JMSSession.pushMessage(JMSSession.java:3253)
     at weblogic.jms.client.JMSSession.invoke(JMSSession.java:4195)
     at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:674)
     at weblogic.messaging.dispatcher.DispatcherServerRef.invoke(DispatcherServerRef.java:262)
     at weblogic.messaging.dispatcher.DispatcherServerRef.handleRequest(DispatcherServerRef.java:134)
     at weblogic.messaging.dispatcher.DispatcherServerRef.access$000(DispatcherServerRef.java:36)
     at weblogic.messaging.dispatcher.DispatcherServerRef$1.run(DispatcherServerRef.java:105)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)
Next, the other thread which is participating in the transaction which is stuck:
"[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=5 tid=0x3adb80a0 nid=0xb30 in Object.wait() [0x3c7af000..0x3c7afd6c]
     at java.lang.Object.wait(Native Method)
     - waiting on <0x0c7a0000> (a oracle.toplink.internal.helper.ConcurrencyManager)
     at java.lang.Object.wait(Object.java:474)
     at oracle.toplink.internal.helper.ConcurrencyManager.acquire(ConcurrencyManager.java:76)
     - locked <0x0c7a0000> (a oracle.toplink.internal.helper.ConcurrencyManager)
     at oracle.toplink.internal.identitymaps.CacheKey.acquire(CacheKey.java:80)
     at oracle.toplink.internal.identitymaps.FullIdentityMap.remove(FullIdentityMap.java:164)
     at oracle.toplink.internal.identitymaps.HardCacheWeakIdentityMap.remove(HardCacheWeakIdentityMap.java:82)
     at oracle.toplink.internal.helper.WriteLockManager.releaseAllAcquiredLocks(WriteLockManager.java:363)
     at oracle.toplink.publicinterface.UnitOfWork.afterTransaction(UnitOfWork.java:2123)
     at oracle.toplink.transaction.AbstractSynchronizationListener.afterCompletion(AbstractSynchronizationListener.java:135)
     at oracle.toplink.transaction.JTASynchronizationListener.afterCompletion(JTASynchronizationListener.java:66)
     at weblogic.transaction.internal.ServerSCInfo.callAfterCompletions(ServerSCInfo.java:862)
     at weblogic.transaction.internal.ServerTransactionImpl.callAfterCompletions(ServerTransactionImpl.java:2913)
     at weblogic.transaction.internal.ServerTransactionImpl.afterCommittedStateHousekeeping(ServerTransactionImpl.java:2806)
     at weblogic.transaction.internal.ServerTransactionImpl.setCommittedUnsync(ServerTransactionImpl.java:2857)
     at weblogic.transaction.internal.ServerTransactionImpl.ackCommit(ServerTransactionImpl.java:1097)
     - locked <0x0c7a0908> (a weblogic.transaction.internal.ServerTransactionImpl)
     at weblogic.transaction.internal.CoordinatorImpl.ackCommit(CoordinatorImpl.java:211)
     at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:517)
     at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:407)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
     at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:403)
     at weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:56)
     at weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:934)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:179)
Is this the same concurrency bug which was fixed in 10.1.3.1??? As I am writing this, I am attempting to build the application with the updated TopLink jar to test for myself. Has anyone else seen this scenario with WebLogic? I should also point out that the problem only occurs when the listener is running on a separate server than the one hosting the JMS queue it reads from. It may be that when the listener runs on the same server, it does not use multiple threads in the transaction.
Any ideas are greatly appreciated.
- Bruno

We've got the same kind of issue with toplink 10.1.3.0.0 and bea weblogic 8.1 SP5.
I 've not tried with 10.1.3.1.0, did you?
Do you have a new status for this issue.
Chris

Similar Messages

[svn] 2692: Bug: BLZ-227 - When using JMS Destination, MessageClient and FlexClient not released from memory when the session times out .

Revision: 2692
Author: [email protected]
Date: 2008-07-31 13:05:35 -0700 (Thu, 31 Jul 2008)
Log Message:
Bug: BLZ-227 - When using JMS Destination, MessageClient and FlexClient not released from memory when the session times out.
QA: Yes
Doc: No
Checkintests: Pass
Details: Fixed a memory leak with JMS adapter. Also a minor tweak to QA build file to not to start the server if the server is already running.
Ticket Links:
http://bugs.adobe.com/jira/browse/BLZ-227
Modified Paths:
blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/services/messaging/adapters/J MSAdapter.java
blazeds/branches/3.0.x/qa/build.xml

Revision: 2692
Author: [email protected]
Date: 2008-07-31 13:05:35 -0700 (Thu, 31 Jul 2008)
Log Message:
Bug: BLZ-227 - When using JMS Destination, MessageClient and FlexClient not released from memory when the session times out.
QA: Yes
Doc: No
Checkintests: Pass
Details: Fixed a memory leak with JMS adapter. Also a minor tweak to QA build file to not to start the server if the server is already running.
Ticket Links:
http://bugs.adobe.com/jira/browse/BLZ-227
Modified Paths:
blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/services/messaging/adapters/J MSAdapter.java
blazeds/branches/3.0.x/qa/build.xml

Authentication error when using JMS service

I'm currently trying to send String messages from LiveCycle to Websphere MQ (Both running on the same server), but I'm having some problems...
I''m quite sure that my WAS setup is correct (or at least close to correct) because I've build some test Java classes that are able to put and get messages from MQ using JMS. However, when I'm usng the LiveCycle JMS service I get the following exception thrown:
[5/26/10 17:46:44:705 CAT] 00000027 QueueMessageS A com.adobe.livecycle.jms.QueueMessageSender sendMessageToQueueWithProperties Error occurred when creating queue connection. Reason: MQJMS2013: invalid security authentication supplied for MQQueueManager.
Since I'm not a Websphere fundi I trawled through Google and was able to figure out that the problem probably lies with the configuration of my queue connection factory. Changing the transport type from "Bindings" to "Client" didn't resolve the problem and I'm rapidly running out of good ideas. Hopefully somebody here would be able to help.
The following info might be useful:
OS = Windows Server 2003
I'm using WAS 6.1.0.29
Websphere MQ is running on the same machine (v6.0)
I've used the Websphere MQ JMS Provider that comes with WAS
I've configured a Queue Connection Factory and a Queue in the server scope
No SSL or anything like that is set up yet
I did notice that when configuring the Queue there is a section titled "WebSphere MQ Queue Connection Properties" where I am able to specify a user Id and password. However, nothing seemed to work. I tried my WAS administration user name, as well as a windows user who is indeed a member of the mqm group. Also tried it without any value, but no luck
On the MQ side I couldn't really find any settings under either the Queue Manager or the Channel that would make much of a difference. Since I was able to access the queues using a servlet deployed on the same WAS instance I'm thinking it has something to do with the way that LC call the JMS provider. But to be honest, I don't really have a clue.
Any help would be much appreciated.
Greg

Haven't solved the problem yet, but here's an update:
I created an "ExecureScript" operation that contains simple Java code to write a message to MQ using the same JMS connection factory and JMS queue. It does work correctly, so clearly my setup it correct enough to send messages from LiveCycle to MQ via JMS.
Here's the code for the ExecuteScript:
//import the classes that the script references
import java.util.List;
import java.lang.String;
import java.util.Map;
import java.util.HashMap;
import javax.jms.*;
import javax.naming.*;
//get a list of file names that are stored in the process variable named files
String strMessage = patExecContext.getProcessDataStringValue("/process_data/@strMessage");
//get connection factory
String strQcf = patExecContext.getProcessDataStringValue("/process_data/@strQcf");
//get queue
String strQ = patExecContext.getProcessDataStringValue("/process_data/@strQ");
try
    // Look up administered objects
    System.out.println("Looking up administered objects...");
    InitialContext initContext;
    initContext = new InitialContext();
    QueueConnectionFactory factory = (QueueConnectionFactory) initContext.lookup(strQcf);
    Queue queue = (Queue) initContext.lookup(strQ);
    initContext.close();
      // Create JMS objects
      System.out.println("Creating JMS objects...");
      QueueConnection connection = factory.createQueueConnection();
      QueueSession session =    connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
    QueueSender sender = session.createSender(queue);
      //Send messages
      TextMessage message = session.createTextMessage(strMessage);
      sender.send(message);
       //Exit
       System.out.println("Exiting...");
       connection.close();
       System.out.println("Goodbye!");
} catch (Exception e)
        e.printStackTrace();
Interestingly I don't provide any authentication information and yet LC is able to connect to MQ
Cheers

InvocationException when use JMS from RA

Hi everybody,
I encountered an interesting thing (I guess a bug).
The JMS Reference Implementation on the J2EE 1.4 RI works if you use JMS API in your servlets or even in you standalone (not deployed) application.
But when you use the same coding inside of your Resource Adapter, like
try{
Context jndiContext= new InitialContext();
javax.jms.ConnectionFactory jmsConnectionFactory =
(javax.jms.ConnectionFactory)jndiContext.lookup
("QueueConnectionFactory");
javax.jms.Connection jmsConnection =
jmsConnectionFactory.createConnection();
javax.jms.Session jmsSession =
jmsConnection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
jmsConnection.close();
}//try
catch (java.lang.Exception ex){
ex.printStackTrace();
}//catch
the Session cannot be created and following Exception is thrown
com.sun.enterprise.InvocationException
     at com.sun.enterprise.util.InvocationManagerImpl.getCurrentInvocation(InvocationManagerImpl.java:188)
     at com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:96)
     at com.sun.enterprise.resource.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:149)
     at com.sun.enterprise.resource.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:58)
     at com.sun.jms.connector.ra.JMSConnectionAdapter.createSession(JMSConnectionAdapter.java:363)
The only cause for this Exception I see, is that J2EE RI doesn't handles yet the case, when the JMS API calls are comming from the threads, which are issued specially for resource adapters. And since even the standalone application using default environment properties to creat an InitialContext can create a Session to a JMS queue, I don't see the reason, why the Resource Adapter shouldn't be able to do this. So I guess, that is a bug.
But anyway, does somebody know a workaround for this case? Or just any ideas?
Thanks,
Eugen

Any luck figuring this out? i'm getting the same exception when appserver 8 does an auto reload of my webapp. For some reason the jdbc connection pools are messed up at that point.

Error While deploying Using JMS Listener- Environmenmt setup? Help!

I have a message driven bean (actually someone else wrote it and left no deployment procedures)
I use a resource provider and adapter
I listen to a jms queue and use a web service to send messages to a bpel process
I compile fine. The code works on other instances. Some environment variables were set that are unknown.
When I deploy to a new oc4j container, I get this error...it is baffling everyone. I really think it has some environment setup I am not thinking of. What could it be?
Someone please help!
What could this refer to? The error message is quite deceiving.
BUILD FAILED
/home/iasgcsdc/DS_028/Send/Send/build.xml:93: Deploy error: Operation
failed with error:
[GCEDC-DS-Send:ejb:SendServiceMDB] - The method init on the
interceptor class mil.usmc.gcss.SendServiceMDB (or one of its superclasses) does not exist or it does not
have the expected argument type: javax.interceptor.InvocationContext.
There is no method init being used that i know of.
The class I wrote SendServiceMDB implements MessageListener
I will post code later.
It uses a '@Resource' annotation at one point...could this be the cause.
Any help or guesses would be so much appreciated. Thanks,
Jason

Hi Peter,
Thanks for the reply.
The issue was with the Memory heap space allocated by Ant.
I have created an environment variable "ANT_OPTS" with the value -Xms512M -Xmx512M
and it works great.
I tried your approach as well and even that works out perfectly.
Edited by: Jaydev Doshi on Oct 23, 2009 10:43 PM

NameNotFoundException when using JMS in a Cluster

Whenever I start my cluster with my test application deployed or on occasion while my cluster is running and I'm deploying my test application I get the following exception:
javax.naming.NameNotFoundException: Unable to resolve 'test'. Resolved ''; remaining name 'test'
at weblogic.jndi.internal.BasicNamingNode.newNameNotFoundException(BasicNamingNode.java:1139)
at weblogic.jndi.internal.BasicNamingNode.lookupHere(BasicNamingNode.java:252)
at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:182)
at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
Following is a snippet of code I'm using that deals with retrieving the topic named 'test':
InitialContext _initialContext = null;
try {
_initialContext = new InitialContext(environment);
_initialContext.lookup("ConnectionFactory");
try {
_initialContext.lookup("test");
} catch (NamingException exception) {
LOG.error("", exception);
} catch (NamingException exception) {
LOG.error("A naming exception has occurred!", exception);
} finally {
if (_initialContext != null) {
try {
_initialContext.close();
} catch (NamingException exception) {
LOG.error("A naming exception has occurred!", exception);
The '_initialContext.lookup("test")' invocation is the one causing the mentioned exception.
I used the snippet of code in my test Servlet's constructor, init(...) and service(...) methods. During Cluster start-up it always fails in the constructor or service(...) method. If I use the code in the service(...) method after Cluster start-up if the service(...) method is hit within a couple of seconds after Cluster start-up the exception is thrown, if I wait for a minute or so the exception is not thrown. It almost looks like the JMS Topic becomes available after some time but is not available during start-up. I would think the JMS Connection Factory and Topics should be set-up and available before invoking my test Servlet's constructor and init(...) method. Did I misconfigure something in my Cluster?
I'm using WebLogic Server 10.3. I have a cluster setup with 1 Administration Server and 3 Managed Nodes. I'm using a Node Manager on each of the nodes to start up the various WebLogic Server instances. Additionally I have the following setup:
- 1 Migratable Target (/w User Preferred Server set to node 1 and /w Constrained Candidate Servers set to nodes 1, 2 and 3)
- 1 JMS Server (targeted at the Migratable Target)
- 1 JMS Module (targeted at the Cluster)
- 1 Connection Factory (/w Default Targeting enabled resulting in the Cluster being targeted)
- 1 Subdeployment
- 1 Topic named 'test' (when defining the Subdeployment I'm only able to target it to the JMS Server)
Any help is appreciated!
Thanks,
Jack...

You can configure JMS servers to run anywhere and you can put
          your connection factories anywhere. If multiple JMS servers are
          going to share a database then they need unique table prefixes. You
          don't need any special DDL.
          _sjz.

Memory leak when using JMS Cache Coordination

We have two Weblogic Server 8.1 processes running Java 1.4.2 on Solaris using TOPLink 10.1.3 with JMS Cache Coordination. We observe that heap is filled with uncollectable instances of TOPLink-mapped classes. In our production system, under full load, this completely fills a 3.6 GB heap in 30 minutes, requiring a process restart. The problem goes away if we turn off cache coordination.
It appears that these instances are UnitOfWork or some other kind of toplink-created clone. We have not yet been able to successfully analyse this problem with a heap profiler.
Has anyone else experienced this this problem? Any suggestions for debugging?
Thanks in advance.

We do set the command manager to asychronous mode. (Our debug tracing confirms that the CommandPropagator method asynchronousPropagateCommand() is invoked, not synchronousPropagateCommand().) We started with asynchronous messaging and actually have never tried running in a synchronous mode.
The Java bug I referenced in my last post (which I have confirmed with a stand-alone test case) indicates that, for Java 1.4.2 and earlier, is is never ok to not start() a Thread -- it will always produce a memory leak. So I am quite surprised than anyone on a pre-1.5 Java had ever had success with synchronous cache coordination messaging. Do you think it is possible all of the pre-release tests and existing customers installations of 10.1.3 cache coordination are using Java 1.5 ?!
Our heap profiling indicates that the instances of CommandPropagator which are pinned (i.e., those not started) are allocated in the run() method of CommandPropagator itself. So it seems that the instance of CommandPropagator, after it is started, allocates another one in its run method. Looking at the bytecodes for the run() method (using javap -c) shows that in one branch of the code a second CommandPropagator is indeed allocated and then handed off to the launchContainerRunnable method of a ServerPlatform.
Since these secondary CommandPropagators are the ones which are not started, we have looked into the WebLogic_8_1_Platform class and found that its implementation launchContainerRunnable (inherited from ServerPlatformBase) does a
new Thread(runnable).start()where the argument runnable is the CommandPropagator.
So the CommandPropagator itself is not started(), but is instead run an another Thread.
We are experimenting with a custom ServerPlatform which overrides launchContainerRunnable:
    server.setServerPlatform(
        new WebLogic_8_1_Platform(server)
            public void launchContainerRunnable(Runnable runnable)
               if (runnable instanceof Thread) ((Thread)runnable).start();
               else super.launchContainerRunnable(runnable);
    ); This starts the argument Runnable directly if it is actually a Thread. Our early, small-scale tests indicate that this change eliminates the memory leak. We are testing now in a production-replicate environment under full load.
But this feels like a hack. I have no idea what TOPLink behavior other than cache coordination flows through this method. Does anyone know what else this ServerPlatform method is used for? Is there a better way to do this? Are there any adverse conquences to our hack? Any suggestions would be appreciated.
Thanks in advance.

Convert JMS Headers from EBCDIC to ASCII when using JMS Bridge (WLS - WMQ)

I have a Java app on Weblogic 11g using a Message Bridge to talk JMS with IBM Websphere MQ. The MQ server is running on IBM z/OS platform which uses EBCDIC encoding. I need to use the Weblogic message selector feature to filter messages on the bridge coming from Websphere MQ. But the JMS Headers of MSGs posted by WMQ are in EBCDIC format. How can I instruct MQ to convert the msg headers to ASCII before put on the bridge? Is there any flag on bindings config file? Or can I set some WMQ specific header before sending the msg on WLS side?
Thanks in advance.

Hi,
Such option is not possible in weblogic but I think this property will help you with in MQ.
Property - Convert EBCDIC newline
Description - EBCDIC code pages contain a new line (NL) character that is not supported by the ASCII code pages (although some ISO variants of ASCII contain an equivalent). If messages are sent from a system that uses EBCDIC code pages (for example, a z/OS system) to a system that uses ASCII, you can control how the EBCDIC newline character is converted into ASCII format.
The default value is NL_TO_LF, which means that the EBCDIC NL character (X'15') is converted to the ASCII line feed character LF (X'0A') for all EBCDIC to ASCII conversions. To convert the EBCDIC NL character according to the conversion tables on your operating system, click TABLE. Note that the results of a TABLE conversion can vary from platform to platform and from language to language; even on the same platform the results might vary if you use different coded character set identifiers (CCSIDs). To convert ISO CCSIDs using the TABLE method and use the NL_TO_LF method for all other CCSIDs, click ISO.
Registry Stanza Key - ConvEBCDICNewline
Also, the MQSeries (not MQSC) adapter provides the data conversion property may handle this conversion as well.
Regards,
Kal

Transactional error when using JMS from stateless session bean

I get a transaction exception when committing a bean method responsible for sending to a JMS topic. This happens only occasionally when two separate threads invoke this method "at the same time".
The scenario:
Two separate threads running two different instances of a stateless session bean (slsb A). This ejb (slsb A) has an injected slsb B which is communicating with the the topic.
Both instances of slsb A are utilising the same instance of slsb B.
The CMT transactions for the two threads start in slsb A from methods with transaction attribute "RequiresNew". All nested methods are to other slsbs and have the transaction attribute "Required". The method in slsb B which sends the message is closing both the session and the connection to the topic.
I'm running Glassfish version 9.1_02 (build b04-fcs) and JMS implementation OpenMQ version 4.1.
Stacktrace (glassfish log):
[#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:5754505514139844608 and onePhase:false due to unkown JMSService server error.|#]
[#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;org.omg.CORBA.INTERNAL:   vmcid: 0x0 minor code: 0 completed: Maybe;commit;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation.|#]
[#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;SubscriptionBean;|EJB5018: An exception was thrown during an ejb invocation on [SubscriptionBean]|#]
[#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;|
javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL:   vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
     at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:321)
     at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
     at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
     at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
     at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
     at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
     at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
     at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
     at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
     at $Proxy130.requestNewSubscription(Unknown Source)
     at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
     at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
     at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
     at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
     at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
     at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
     at $Proxy129.requestNewSubscription(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
     at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
     at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
     at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
     at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
     at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
     at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
     at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
     at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
     at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
     at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
     at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
     at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
     at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
     at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
     at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
     at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
     at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
     at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
     at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
     at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
     at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
     at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
     at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
     at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
     at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
     at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
     at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
     at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
     at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
     at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
     at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
     at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
     at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
     at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
     at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
     at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
     at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
     at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
     at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
     at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
     at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
     at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
     at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
IMQ broker log:
[09/Sep/2008:13:00:40 CEST] ERROR CommitTransaction: commit failed. Connection ID: 5754505514139844608, Transaction ID: 0:
com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown Transaction 0
     at com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.commitTransaction(ProtocolImpl.java:630)
     at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.commitTransaction(IMQDirectService.java:1735)
     at com.sun.messaging.jms.ra.DirectXAResource.commit(DirectXAResource.java:201)
     at com.sun.jts.jtsxa.OTSResourceImpl.commit(OTSResourceImpl.java:114)
     at com.sun.jts.CosTransactions.RegisteredResources.distributeCommit(RegisteredResources.java:795)
     at com.sun.jts.CosTransactions.TopCoordinator.commit(TopCoordinator.java:2111)
     at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:403)
     at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
     at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
     at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
     at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
     at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
     at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
     at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
     at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
     at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
     at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
     at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
     at $Proxy130.requestNewSubscription(Unknown Source)
     at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
     at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
     at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
     at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
     at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
     at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
     at $Proxy129.requestNewSubscription(Unknown Source)
     at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
     at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
     at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
     at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
     at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
     at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
     at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
     at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
     at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
     at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
     at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
     at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
     at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
     at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
     at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
     at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
     at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
     at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
     at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
     at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
     at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
     at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
     at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
     at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
     at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
     at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
     at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
     at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
     at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
     at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
     at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
     at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
     at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
     at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
     at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
     at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
     at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
     at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
     at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
     at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
     at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
     at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
     at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
     at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
     at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
     at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
     at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Have anyone any idea why this should fail?
Regards,
Jon

I would suggest opening a case with [email protected] FWIW, I recall seeing
          something like this in WLS 6.0. I believe it is fixed in WLS 6.1
          -- Rob
          Chris Dupuy wrote:
          > Btw, this occurs when I create an stateful session bean that ends up
          > throwing an exception and setRollbackOnly() is called. From that point
          > forward, my logs fill with this message.
          >
          > Chris
          >
          > "Chris Dupuy" <[email protected]> wrote in message
          > news:[email protected]..
          > > anyone know what this means, and what you can do about it?
          > >
          > >
          > > <Error> <ConnectionManager> <atossd03> <cbeyondServer> <ExecuteThread:
          > '14'
          > > for queue: 'd
          > > efault'> <> <> <000000> <Closing:
          > 'weblogic.rjvm.t3.T3JVMConnection@488831'
          > > because of: 'Server received a message over an uniniti
          > > alized connection: 'JVMMessage from: 'null' to:
          > >
          > '5825313123619479267S:10.6.6.40:[8000,8000,8001,8001,8000,8001,-1]:cbeyond:c
          > > beyond
          > > Server' cmd: 'CMD_REQUEST', QOS: '101', responseId: '2', invokableId: '1',
          > > flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev o
          > > ffset: '204'''>
          > >
          > >
          > >

Problem when getting resultset when using connection pooling in weblogic

Hello,
I am new to database connection pooling. I am using weblogic server, Java 1.6, MySql database. I have done connection pooling in weblogic server. The problem arise when I try to run select query I cannot fetch data in ResultSet. For insert it works fine...
import java.io.Serializable;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;
import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.sql.DataSource;
public class DatabaseToText implements Serializable {
public DatabaseToText() {
super();
// TODO Auto-generated constructor stub
public static void main(String[] args) {
Connection conn;
Statement stmt;
ResultSet rs;
String str1, str2;
List l1 = new ArrayList();
try {
System.out.println("in try block");
Properties prop = new Properties();
prop.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
prop.put(Context.PROVIDER_URL, "t3://localhost:7001");
System.out.println("properties are set ");
Context ctx = new InitialContext(prop);
System.out.println("b4 lookup(mysqljndi)");
Object obj = ctx.lookup("mysqljndi"); // java:comp/env/CPDS
System.out.println("afta lookup(mysqljndi)");
DataSource ds = (DataSource) obj;
conn = ds.getConnection();
stmt = conn.createStatement();
String query = "select * from logindb.userregister";
System.out.println("query is = " + query);
rs = stmt.executeQuery(query);
System.out.println("size of rs is :: " + rs.getFetchSize());
if (rs != null) {
while (rs.next()) {
str1 = rs.getString(0);
str2 = rs.getString(1);
System.out.println("username is :: " + str1 + "password is : " + str2);
} else {
System.out.println("no values get fetched");
ctx.close();
} catch (Exception e) {
e.printStackTrace();
OUTPUT IN CONSOLE
in try block
properties are set
b4 lookup(mysqljndi)
afta lookup(mysqljndi)
query is = select * from logindb.userregister
size of rs is :: 0
java.sql.SQLException: weblogic.rmi.extensions.RemoteRuntimeException: Unexpected Exception - with nested exception:
[java.rmi.MarshalException: error marshalling return; nested exception is:
     java.io.NotSerializableException: com.mysql.jdbc.ResultSet]
     at weblogic.jdbc.rmi.SerialResultSet.next(SerialResultSet.java:89)
     at DatabaseToText.main(DatabaseToText.java:69)
Record is getting inserted but when i use select query i cannot get the output...
Regards,

This problem is solved in JDBC section of this forum

Account Password Changed When Using OCI Drivers With WebLogic 6.0

Hello all,
Could be I am losing my mind but I saw some strange bahavior and I was wondering if anyone could offer an explination. We're running BEA WL6.0sp2 on an HPUX box with both an 8.1.7 client and server installation for development. We noticed that when we try to use the OCI driver to connect to our database, the password for our account is being changed on connection. This is definitely repeatable as we demonstrated it for the DBAs while they yelled at us. I highly doubt there is anything in WL that would cause the problem and everything works fine with the Thin drivers, with the JDrivers provided by BEA and with the credentials from SQL+.
Our problem is we need the Layer 2 OCI support. Is there something in the OCI client installation that would cause this behavior?

Hello all,
Could be I am losing my mind but I saw some strange bahavior and I was wondering if anyone could offer an explination. We're running BEA WL6.0sp2 on an HPUX box with both an 8.1.7 client and server installation for development. We noticed that when we try to use the OCI driver to connect to our database, the password for our account is being changed on connection. This is definitely repeatable as we demonstrated it for the DBAs while they yelled at us. I highly doubt there is anything in WL that would cause the problem and everything works fine with the Thin drivers, with the JDrivers provided by BEA and with the credentials from SQL+.
Our problem is we need the Layer 2 OCI support. Is there something in the OCI client installation that would cause this behavior?

ArrayIndexOutOfBoundException when using Callable Statement in Weblogic 8.1

Hi all,
We recently ported our application from 6.1 to 8.1.
I have noticed the following exception in 8.1 (which was working fine in 6.1)
java.lang.ArrayIndexOutOfBoundsException: 7
[ERROR] nfusion.admin.UpdateBureauLogin.5 131575 2003-10-15 16:21:58,385 Exception
caught
java.lang.ArrayIndexOutOfBoundsException: 7
at oracle.jdbc.dbaccess.DBDataSetImpl._getDBItem(DBDataSetImpl.java:303)
at oracle.jdbc.dbaccess.DBDataSetImpl._createOrGetDBItem(DBDataSetImpl.java:542)
at oracle.jdbc.dbaccess.DBDataSetImpl.setBytesBindItem(DBDataSetImpl.java:1642)
at oracle.jdbc.driver.OraclePreparedStatement.setItem(OraclePreparedStatement.java:745)
at oracle.jdbc.driver.OraclePreparedStatement.setString(OraclePreparedStatement.java:1083)
at weblogic.jdbc.wrapper.PreparedStatement.setString(PreparedStatement.java:415)
at com.ecredit.nfusion.businessobject.bureau.dao.DefaultBureauLoginDao.store(DefaultBureauLoginDao.java:200)
at com.ecredit.nfusion.businessobject.bureau.BureauManagerBean.updateBureauLogins(BureauManagerBean.java:940)
at com.ecredit.nfusion.businessobject.bureau.BureauManagerBean.setDetails(BureauManagerBean.java:424)
at com.ecredit.nfusion.businessobject.bureau.BureauManagerBean_lptk9u_EOImpl.setDetails(BureauManagerBean_lptk9u_EOImpl.java:46)
at com.ecredit.nfusion.businessservice.admin.UpdateBureauLoginHandler.execute(UpdateBureauLoginHandler.java:73)
at com.ecredit.nfusion.platform.requestproxy.RequestProxyBean.execute(RequestProxyBean.java:155)
at com.ecredit.nfusion.platform.requestproxy.RequestProxyBean_vc5299_EOImpl.execute(RequestProxyBean_vc5299_EOImpl.java:46)
at com.ecredit.nfusion.platform.requestdelegate.AbstractRequestDelegate.invokeProxy(AbstractRequestDelegate.java:135)
at com.ecredit.nfusion.platform.requestdelegate.HTMLRequestDelegate.execute(HTMLRequestDelegate.java:240)
at com.ecredit.nfusion.platform.inboundadapter.HTTPInboundAdapter.service(HTTPInboundAdapter.java:184)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6291)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3575)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2573)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)
I am not able to figure out why this is happening in WL 8.1 and is working fine
in 6.1.
We are using Oracle 8.1.7 database. I have downloaded the thin driver for 8.1.7
(classes12.zip) and have included it before the weblogic jar files (in the startWeblogic.sh
file).
Any help would be greatly appreciated.
Regards,
-Rajan

Rajan Desai wrote:
I already have classes12.zip for Oracle 8.1.7 in my class path (before weblogic.jar
file).
Inspite of that it is giving this error.
Any other suggestion to resolve this problem?Yes, but just to be sure, would you show us the first 20 or so lines of the server log?
It should have a line describing the actual java command that starts the server, including
the class path that the startup script assembles for this line.
Thanks,
Joe
>
>
-RD
Mitesh Patel <[email protected]> wrote:
In 8.1, default oracle thin driver is changed from 817 to 920. This might
be bug in new oracle driver.
Please put classes12.zip file from oracle 817 version, that might resolve
your problem.
Thanks,
Mitesh
Rajan Desai wrote:
Hi all,
We recently ported our application from 6.1 to 8.1.
I have noticed the following exception in 8.1 (which was working finein 6.1)
java.lang.ArrayIndexOutOfBoundsException: 7
[ERROR] nfusion.admin.UpdateBureauLogin.5 131575 2003-10-15 16:21:58,385Exception
caught
java.lang.ArrayIndexOutOfBoundsException: 7
at oracle.jdbc.dbaccess.DBDataSetImpl._getDBItem(DBDataSetImpl.java:303)
at oracle.jdbc.dbaccess.DBDataSetImpl._createOrGetDBItem(DBDataSetImpl.java:542)
at oracle.jdbc.dbaccess.DBDataSetImpl.setBytesBindItem(DBDataSetImpl.java:1642)
at oracle.jdbc.driver.OraclePreparedStatement.setItem(OraclePreparedStatement.java:745)
at oracle.jdbc.driver.OraclePreparedStatement.setString(OraclePreparedStatement.java:1083)
at weblogic.jdbc.wrapper.PreparedStatement.setString(PreparedStatement.java:415)
at com.ecredit.nfusion.businessobject.bureau.dao.DefaultBureauLoginDao.store(DefaultBureauLoginDao.java:200)
at com.ecredit.nfusion.businessobject.bureau.BureauManagerBean.updateBureauLogins(BureauManagerBean.java:940)
at com.ecredit.nfusion.businessobject.bureau.BureauManagerBean.setDetails(BureauManagerBean.java:424)
at com.ecredit.nfusion.businessobject.bureau.BureauManagerBean_lptk9u_EOImpl.setDetails(BureauManagerBean_lptk9u_EOImpl.java:46)
at com.ecredit.nfusion.businessservice.admin.UpdateBureauLoginHandler.execute(UpdateBureauLoginHandler.java:73)
at com.ecredit.nfusion.platform.requestproxy.RequestProxyBean.execute(RequestProxyBean.java:155)
at com.ecredit.nfusion.platform.requestproxy.RequestProxyBean_vc5299_EOImpl.execute(RequestProxyBean_vc5299_EOImpl.java:46)
at com.ecredit.nfusion.platform.requestdelegate.AbstractRequestDelegate.invokeProxy(AbstractRequestDelegate.java:135)
at com.ecredit.nfusion.platform.requestdelegate.HTMLRequestDelegate.execute(HTMLRequestDelegate.java:240)
at com.ecredit.nfusion.platform.inboundadapter.HTTPInboundAdapter.service(HTTPInboundAdapter.java:184)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6291)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3575)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2573)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)
I am not able to figure out why this is happening in WL 8.1 and isworking fine
in 6.1.
We are using Oracle 8.1.7 database. I have downloaded the thin driverfor 8.1.7
(classes12.zip) and have included it before the weblogic jar files(in the startWeblogic.sh
file).
Any help would be greatly appreciated.
Regards,
-Rajan

BPM for WebLogic 10.3 JMS listener problem: SecurityException

Hi!
I have a BPM 10.3 engine running on WebLogic 10.3 and a BPM process that uses JMS listener global automatic activity. The JMS queue is located in a WebLogic 8.1 server.
The global activity receives a message and tries to create a new process instance. At runtime a strange error occurs (see below). If I just log the message and comment the process creation out, the message is successfully consumed, but with the creation part it is not. The process creation itself is not the problem because other message listeners that call other process activities fail with similar errors.
Btw, it's working in Studio, but not in WL10.
Could someone explain me what happens and how to fix it?
Have I misconfigured something?
Thanks in advance,
Jaanus
The BPM engine log:
The task could not be successfully executed.
Reason: 'fuego.papi.exception.ActivityFailedException: Activity '/MyProcess#Default-1.0/Begin[Begin]' task 'BeginIn' could not execute successfully.
Detail:Method: 'BeginIn', Exception: 'Process execution engine execution error.'
Caused by: Activity '/MyProcess#Default-1.0/Begin[Begin]' task 'BeginIn' could not execute successfully.
Detail:Method: 'BeginIn', Exception: 'Process execution engine execution error.'
Caused by: Process execution engine execution error.
Caused by: Connector [TrinityEngine_J2EE_RUNTIME_FUEGOLABS_ARG:SQL:REMOTE_JDBC] caused an exception when getting a resource of type [0].
Detail:Connector [TrinityEngine_J2EE_RUNTIME_FUEGOLABS_ARG:SQL:REMOTE_JDBC] caused an exception when getting a resource of type [0].
Caused by: [Security:090398]Invalid Subject: principals=[weblogic, Administrators]
fuego.lang.ComponentExecutionException: The task could not be successfully executed.
Reason: 'fuego.papi.exception.ActivityFailedException: Activity '/MyProcess#Default-1.0/Begin[Begin]' task 'BeginIn' could not execute successfully.
Detail:Method: 'BeginIn', Exception: 'Process execution engine execution error.'
     at fuego.server.execution.EngineExecutionContext.invokeMethodAsCil(EngineExecutionContext.java:1094)
     at fuego.server.execution.EngineExecutionContext.runCil(EngineExecutionContext.java:1280)
     at fuego.server.execution.GlobalAutomaticJMSListeningHelper.executeJmsListener(GlobalAutomaticJMSListeningHelper.java:94)
     at fuego.server.AbstractProcessBean$45.execute(AbstractProcessBean.java:3017)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startBaseTransaction(TransactionAction.java:470)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:551)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:212)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:123)
     at fuego.server.execution.EngineExecution.executeImmediate(EngineExecution.java:66)
     at fuego.server.AbstractProcessBean.runGlobalJmsActivity(AbstractProcessBean.java:3023)
     at fuego.server.execution.GlobalJMSExecutor$1.run(GlobalJMSExecutor.java:113)
     at fuego.ejbengine.EJBProcessBean.executeTask(EJBProcessBean.java:147)
     at fuego.server.execution.GlobalJMSExecutor.execute(GlobalJMSExecutor.java:105)
     at fuego.ejbengine.EJBGlobalJMSExecutor.access$400(EJBGlobalJMSExecutor.java:43)
     at fuego.ejbengine.EJBGlobalJMSExecutor$JMSExecutorWorker.run(EJBGlobalJMSExecutor.java:213)
     at java.lang.Thread.run(Thread.java:619)
Caused by: fuego.papi.exception.ActivityFailedException: Activity '/MyProcess#Default-1.0/Begin[Begin]' task 'BeginIn' could not execute successfully.
Detail:Method: 'BeginIn', Exception: 'Process execution engine execution error.'
     at fuego.papi.exception.ActivityFailedException.create(ActivityFailedException.java:66)
     at fuego.server.AbstractProcessBean.createActivityFailedException(AbstractProcessBean.java:3690)
     at fuego.server.AbstractProcessBean.internalCreateInstance(AbstractProcessBean.java:4326)
     at fuego.server.AbstractProcessBean._doCreateInstance(AbstractProcessBean.java:3650)
     at fuego.server.AbstractProcessBean.createInstance(AbstractProcessBean.java:665)
     at fuego.server.AbstractProcessBean.createInstance(AbstractProcessBean.java:736)
     at fuego.components.Process.createInstance(Process.java:106)
     at fuego.components.ProcessInstance.create(ProcessInstance.java:392)
     at fuego.components.ProcessInstance.create(ProcessInstance.java:503)
     at oracle.MyProcess.Default_1_0.Instance.CIL_ootaJMSSonumit(Instance.xcdl:12)
     at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at fuego.server.execution.EngineExecutionContext.invokeMethodAsCil(EngineExecutionContext.java:1085)
     ... 16 more
Caused by: fuego.papi.impl.EngineExecutionException: Process execution engine execution error.
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:139)
     at fuego.server.execution.EngineExecution.executeImmediate(EngineExecution.java:66)
     at fuego.server.AbstractProcessBean.internalCreateInstance(AbstractProcessBean.java:4320)
     ... 27 more
Caused by: class fuego.lang.RuntimeExceptionShell ->> fuego.connector.ConnectorException: Connector [TrinityEngine_J2EE_RUNTIME_FUEGOLABS_ARG:SQL:REMOTE_JDBC] caused an exception when getting a resource of type [0].
Detail:Connector [TrinityEngine_J2EE_RUNTIME_FUEGOLABS_ARG:SQL:REMOTE_JDBC] caused an exception when getting a resource of type [0].
     at fuego.server.service.EngineConnectorService.getConnection(EngineConnectorService.java:581)
     at fuego.server.service.EngineConnectorService.getEngineConnection(EngineConnectorService.java:300)
     at fuego.transaction.TransactionAction.getEngineHandle(TransactionAction.java:179)
     at fuego.server.execution.EngineExecutionContext.getEngineHandle(EngineExecutionContext.java:443)
     at fuego.server.AbstractInstanceService.create(AbstractInstanceService.java:302)
     at fuego.server.execution.microactivity.BeginMicroActivity.createInstance(BeginMicroActivity.java:95)
     at fuego.server.AbstractProcessBean$53.execute(AbstractProcessBean.java:3642)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startNestedTransaction(TransactionAction.java:527)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:548)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:213)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:125)
     at fuego.server.execution.EngineExecution.executeImmediate(EngineExecution.java:66)
     at fuego.server.AbstractProcessBean.internalCreateInstance(AbstractProcessBean.java:4320)
     at fuego.server.AbstractProcessBean._doCreateInstance(AbstractProcessBean.java:3650)
     at fuego.server.AbstractProcessBean.createInstance(AbstractProcessBean.java:665)
     at fuego.server.AbstractProcessBean.createInstance(AbstractProcessBean.java:736)
     at fuego.components.Process.createInstance(Process.java:106)
     at fuego.components.ProcessInstance.create(ProcessInstance.java:392)
     at fuego.components.ProcessInstance.create(ProcessInstance.java:503)
     at oracle.MyProcess.Default_1_0.Instance.CIL_ootaJMSSonumit(Instance.xcdl:12)
     at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at fuego.server.execution.EngineExecutionContext.invokeMethodAsCil(EngineExecutionContext.java:1085)
     at fuego.server.execution.EngineExecutionContext.runCil(EngineExecutionContext.java:1280)
     at fuego.server.execution.GlobalAutomaticJMSListeningHelper.executeJmsListener(GlobalAutomaticJMSListeningHelper.java:94)
     at fuego.server.AbstractProcessBean$45.execute(AbstractProcessBean.java:3017)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startBaseTransaction(TransactionAction.java:472)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:551)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:213)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:125)
     ... 8 more
Caused by: fuego.connector.ConnectorException: Connector [TrinityEngine_J2EE_RUNTIME_FUEGOLABS_ARG:SQL:REMOTE_JDBC] caused an exception when getting a resource of type [0].
Detail:Connector [TrinityEngine_J2EE_RUNTIME_FUEGOLABS_ARG:SQL:REMOTE_JDBC] caused an exception when getting a resource of type [0].
     at fuego.connector.ConnectorException.exceptionOnGetResource(ConnectorException.java:95)
     at fuego.connector.ConnectorTransaction.getResource(ConnectorTransaction.java:324)
     at fuego.connector.ConnectorTransaction.getResource(ConnectorTransaction.java:298)
     at fuego.connector.JDBCHelper.getConnection(JDBCHelper.java:41)
     at fuego.server.service.EngineConnectorService.getConnection(EngineConnectorService.java:578)
     at fuego.server.service.EngineConnectorService.getEngineConnection(EngineConnectorService.java:300)
     at fuego.transaction.TransactionAction.getEngineHandle(TransactionAction.java:179)
     at fuego.server.execution.EngineExecutionContext.getEngineHandle(EngineExecutionContext.java:443)
     at fuego.server.AbstractInstanceService.create(AbstractInstanceService.java:302)
     at fuego.server.execution.microactivity.BeginMicroActivity.createInstance(BeginMicroActivity.java:91)
     at fuego.server.AbstractProcessBean$53.execute(AbstractProcessBean.java:3642)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startNestedTransaction(TransactionAction.java:527)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:548)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:212)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:123)
     at fuego.server.execution.EngineExecution.executeImmediate(EngineExecution.java:66)
     at fuego.server.AbstractProcessBean.internalCreateInstance(AbstractProcessBean.java:4320)
     at fuego.server.AbstractProcessBean._doCreateInstance(AbstractProcessBean.java:3650)
     at fuego.server.AbstractProcessBean.createInstance(AbstractProcessBean.java:665)
     at fuego.server.AbstractProcessBean.createInstance(AbstractProcessBean.java:736)
     at fuego.components.Process.createInstance(Process.java:106)
     at fuego.components.ProcessInstance.create(ProcessInstance.java:392)
     at fuego.components.ProcessInstance.create(ProcessInstance.java:503)
     at oracle.MyProcess.Default_1_0.Instance.CIL_ootaJMSSonumit(Instance.xcdl:12)
     at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at fuego.server.execution.EngineExecutionContext.invokeMethodAsCil(EngineExecutionContext.java:1085)
     at fuego.server.execution.EngineExecutionContext.runCil(EngineExecutionContext.java:1280)
     at fuego.server.execution.GlobalAutomaticJMSListeningHelper.executeJmsListener(GlobalAutomaticJMSListeningHelper.java:94)
     at fuego.server.AbstractProcessBean$45.execute(AbstractProcessBean.java:3017)
     at fuego.server.execution.DefaultEngineExecution$AtomicExecutionTA.runTransaction(DefaultEngineExecution.java:304)
     at fuego.transaction.TransactionAction.startBaseTransaction(TransactionAction.java:470)
     at fuego.transaction.TransactionAction.startTransaction(TransactionAction.java:551)
     at fuego.transaction.TransactionAction.start(TransactionAction.java:212)
     at fuego.server.execution.DefaultEngineExecution.executeImmediate(DefaultEngineExecution.java:123)
     ... 8 more
Caused by: java.lang.SecurityException: [Security:090398]Invalid Subject: principals=[weblogic, Administrators]
     at weblogic.security.service.SecurityServiceManager.seal(Unknown Source)
     at weblogic.security.service.IdentityUtility.authenticatedSubjectToIdentity(Unknown Source)
     at weblogic.security.service.RoleManager.getRoles(Unknown Source)
     at weblogic.security.service.AuthorizationManager.isAccessAllowed(Unknown Source)
     at weblogic.jndi.internal.ServerNamingNode.checkPermission(ServerNamingNode.java:442)
     at weblogic.jndi.internal.ServerNamingNode.checkLookup(ServerNamingNode.java:423)
     at weblogic.jndi.internal.ServerNamingNode.lookupHere(ServerNamingNode.java:180)
     at weblogic.jndi.internal.BasicNamingNode.lookup(BasicNamingNode.java:206)
     at weblogic.jndi.internal.WLEventContextImpl.lookup(WLEventContextImpl.java:254)
     at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:380)
     at javax.naming.InitialContext.lookup(InitialContext.java:392)
     at fuego.connector.impl.BaseRemoteConnector.getReferencedObject(BaseRemoteConnector.java:116)
     at fuego.connector.impl.BaseRemoteConnector.getReferencedObject(BaseRemoteConnector.java:107)
     at fuego.connector.impl.RemoteJDBCConnector.getConnection(RemoteJDBCConnector.java:75)
     at fuego.connector.impl.RemoteJDBCConnector.getConnection(RemoteJDBCConnector.java:64)
     at fuego.connector.impl.RemoteJDBCConnector.getResource(RemoteJDBCConnector.java:147)
     at fuego.connector.ConnectorTransaction.getResource(ConnectorTransaction.java:319)
     ... 43 more

I managed to solve the problem by configuring the domain's security settings on both WebLogic servers as follows:
*) checked "Anonymous Admin Lookup Enabled",
*) entered the same value to Advanced->Credential on both WLs.

Java.sql.SQLException: Cannot call rollback when using distributed transac

Hi all,
I am getting the below exception trace when I tried to rollback the data in WLI.I am getting the db connection Object from DBControl.
java.sql.SQLException: Cannot call rollback when using distributed transactions
at weblogic.jdbc.wrapper.JTAConnection.rollback(JTAConnection.java:313)
at controls.DailyFeedFileJavaImpl.excuteBatch(DailyFeedFileJavaImpl.jcs:
904)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.bea.wlw.runtime.core.dispatcher.DispMethod.invoke(DispMethod.java
:371)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:42
3)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:39
6)
at com.bea.wlw.runtime.jcs.container.JcsProxy.invoke(JcsProxy.java:381)
at $Proxy59.excuteBatch(Unknown Source)
at QnbDailyFeedProcess.feedFileJavaObjExcuteBatch(QnbDailyFeedProcess.jp
d:274)
at QnbDailyFeedProcess_wf$ImplControlSend15.invoke(QnbDailyFeedProcess_w
f.java:146)
at com.bea.wli.bpm.runtime.Perform.execute(Perform.java:32)
at com.bea.wli.bpm.runtime.ProcessState.executeInternalCallback(ProcessS
tate.java:726)
at QnbDailyFeedProcess_wf$_ProcessState.executeInternalCallback(QnbDaily
FeedProcess_wf.java:311)
at com.bea.wli.bpm.runtime.ProcessState.executeInternalCallback(ProcessS
tate.java:685)
at com.bea.wli.bpm.runtime.ProcessState.processNodeOrchestration(Process
State.java:681)
at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.bea.wlw.runtime.core.dispatcher.DispMethod.invoke(DispMethod.java
:371)
at com.bea.wli.bpm.runtime.JpdInternalDispMethod.invoke(JpdInternalDispM
ethod.java:87)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:42
3)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:39
6)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:24

shanmuga gomathi nayagam wrote:
Hi all,
I am getting the below exception trace when I tried to rollback the data in WLI.I am getting the db connection Object from DBControl.
java.sql.SQLException: Cannot call rollback when using distributed transactions
at weblogic.jdbc.wrapper.JTAConnection.rollback(JTAConnection.java:313)Hi, Ideally, you should obtain the Transaction object and roll it back/ set it
to rollback only.
Joe
at controls.DailyFeedFileJavaImpl.excuteBatch(DailyFeedFileJavaImpl.jcs:
904)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.bea.wlw.runtime.core.dispatcher.DispMethod.invoke(DispMethod.java
:371)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:42
3)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:39
6)
at com.bea.wlw.runtime.jcs.container.JcsProxy.invoke(JcsProxy.java:381)
at $Proxy59.excuteBatch(Unknown Source)
at QnbDailyFeedProcess.feedFileJavaObjExcuteBatch(QnbDailyFeedProcess.jp
d:274)
at QnbDailyFeedProcess_wf$ImplControlSend15.invoke(QnbDailyFeedProcess_w
f.java:146)
at com.bea.wli.bpm.runtime.Perform.execute(Perform.java:32)
at com.bea.wli.bpm.runtime.ProcessState.executeInternalCallback(ProcessS
tate.java:726)
at QnbDailyFeedProcess_wf$_ProcessState.executeInternalCallback(QnbDaily
FeedProcess_wf.java:311)
at com.bea.wli.bpm.runtime.ProcessState.executeInternalCallback(ProcessS
tate.java:685)
at com.bea.wli.bpm.runtime.ProcessState.processNodeOrchestration(Process
State.java:681)
at sun.reflect.GeneratedMethodAccessor193.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.bea.wlw.runtime.core.dispatcher.DispMethod.invoke(DispMethod.java
:371)
at com.bea.wli.bpm.runtime.JpdInternalDispMethod.invoke(JpdInternalDispM
ethod.java:87)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:42
3)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:39
6)
at com.bea.wlw.runtime.core.container.Invocable.invoke(Invocable.java:24

When using rabbitmq-jms for vFabric RabbitMQ javax.jms.Message.getJMSDestination does not return the actual destination when it is received from a consumer listening on a Topic with a wild card

When using rabbitmq-jms for vFabric RabbitMQ javax.jms.Message.getJMSDestination does not return the actual destination when it is received from a consumer listening on a Topic with a wild card. I have tested with both 1.0.3 and 1.0.5 clients with RabbitMQ 3.1.5.
I was wondering if the community was aware of this problem and if there are any workarounds? If not what is the proper channel to file a bug report. An example code snippet is below. The test fails because the TextMessageMatcher expects the destination passed in on construction (second parameter) to equal the desination on the message received (aquired from getJMSDestination).
        Mockery context = new Mockery();
        final MessageListener messageListener = context.mock(MessageListener.class);
        final Latch latch = new LatchImpl();
        final String prefix = "test" + System.currentTimeMillis();
        context.checking(new Expectations() {
                oneOf(messageListener).onMessage(with(new TextMessageMatcher("MSG1", prefix + ".1234")));
                will(new CustomAction("release latch") {
                    @Override
                    public Object invoke(Invocation invocation) throws Throwable {
                        latch.unlatch();
                        return null;
        final Connection connection = createConnection(null, null);
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        connection.start();
        Topic wildcardTopic = (Topic) getInitialContext().lookup(prefix + "." + "#");
        Topic destination = (Topic) getInitialContext().lookup(prefix + ".1234");
        final MessageConsumer consumer = session.createConsumer(wildcardTopic);
        consumer.setMessageListener(messageListener);
        MessageProducer producer = session.createProducer(null);
        producer.send(destination, session.createTextMessage("MSG1"));
        latch.await(5000);
        connection.close();
        Thread.sleep(5);
        context.assertIsSatisfied();

Check where your MDB sends the [response] messages to.

Deadlock in TopLink when using JMS listener on WebLogic

Similar Messages

Maybe you are looking for