Concurrency bug in SSLEngine?

We are using the Java 1.5 SSLEngine to perform some non-blocking SSL network comms, and are seeing a Java-level deadlock occurring that doesn't seem to be covered in the "concurrency notes" in the javadocs for SSLEngine.
Our software has multiple threads calling into methods that perform either a wrap or unwrap operation. After either operation, if the NEED_TASK flag is set in the SSLEngineResult, we will perform all delegated tasks within the current thread. As I understand it, wrap/unwrap can occur simultaneously in multiple threads, and it is merely important to prevent simultaneous calls to either of the methods. I see no mention of the fact that a delegated task cannot be performed concurrently with either a wrap or unwrap, but this is where we are deadlocking.
Reference the following deadlock from our thread dump:
Found one Java-level deadlock:
=============================
"nbcsWriteWorker-6":
  waiting to lock monitor 0x0013c378 (object 0xbb064200, a com.sun.net.ssl.internal.ssl.SSLEngineImpl),
  which is held by "nbcsReadWorker-0"
"nbcsReadWorker-0":
  waiting to lock monitor 0x0013c3c0 (object 0xbb076290, a java.lang.Object),
  which is held by "nbcsWriteWorker-6"
Java stack information for the threads listed above:
===================================================
"nbcsWriteWorker-6":
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.getConnectionState(SSLEngineImpl.java:472)
        - waiting to lock <0xbb064200> (a com.sun.net.ssl.internal.ssl.SSLEngineImpl)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1067)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1026)
        - locked <0xbb076290> (a java.lang.Object)
        at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:411)
        at (our method to encode outbound data)
"nbcsReadWorker-0":
        at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:594)
        - waiting to lock <0xbb076290> (a java.lang.Object)
        at com.sun.net.ssl.internal.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:698)
        at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:624)
        at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:160)
        at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
        at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Handshaker.java:437)
        at java.security.AccessController.doPrivileged(Native Method)
        at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Handshaker.java:932)
        - locked <0xbb064200> (a com.sun.net.ssl.internal.ssl.SSLEngineImpl)
        at (our method to run all delegated tasks for the given socket)
        at (our method to encode inbound data, wherein we performed an unwrap and determined there are tasks to run)As you can see, there is a deadlock between objects locked inside of the wrap call and objects locked inside of the Handshaker$DelegatedTask. I can guard against this occurring by synchronizing against objects that prevent tasks from being run at the same time as either a wrap or unwrap, but I'm concerned that this might adversely affect performance.
Is a bug in the SSLEngine, or just a documentation problem?
(We are seeing this occur between 2 Solaris machines, for what it's worth.)

The plot thickens...
After adding locking objects to prevent concurrent execution of either a wrap or unwrap with the execution of a handshaking task, we have run across yet another deadlock inside of the SSLEngine code.
This time actually between wrap and unwrap tasks themselves, which Sun explicitely states can be run concurrently.
We are running our application on a dual proc system running Solaris and JRE 1.5.0_07-b03.
I'm thinking the reason we are running across this where others haven't has to do with the fact that we are essentially running these operations out of a threadpool wherein the tasks are dispatched as we select for read or write on the socket. We are guaranteeing the order of reads and the order of writes, but each is in a different FIFO queue for execution. Thus it is not unusual that both a wrap and unwrap would be executing on the same SSLEngine concurrently.
Here is the stack dump info for the deadlock:
Found one Java-level deadlock:
=============================
"nbcsReadWorker-240":
  waiting to lock monitor 0x08182814 (object 0xbeaa7250, a java.lang.Object),
  which is held by "nbcsWriteWorker-203"
"nbcsWriteWorker-203":
  waiting to lock monitor 0x081827d4 (object 0xbeaa7020, a com.sun.net.ssl.internal.ssl.SSLEngineImpl),
  which is held by "nbcsReadWorker-240"
Java stack information for the threads listed above:
===================================================
"nbcsReadWorker-240":
        at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:594)
        - waiting to lock <0xbeaa7250> (a java.lang.Object)
        at com.sun.net.ssl.internal.ssl.ServerHandshaker.sendChangeCipherAndFinish(ServerHandshaker.java:984)
        at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientFinished(ServerHandshaker.java:944)
        at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:239)
        at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
        at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:914)
        - locked <0xbeaa7020> (a com.sun.net.ssl.internal.ssl.SSLEngineImpl)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:782)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:674)
        - locked <0xbeaa7258> (a java.lang.Object)
        at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:566)
        at (our code performing a read)
"nbcsWriteWorker-203":
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.getHSStatus(SSLEngineImpl.java:430)
        - waiting to lock <0xbeaa7020> (a com.sun.net.ssl.internal.ssl.SSLEngineImpl)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1075)
        at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1026)
        - locked <0xbeaa7250> (a java.lang.Object)
        at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:411)
        at (our code performing a write)So I guess we're stuck for now synchronizing any wrap/unwrap/task operation on a single object per SSLEngine, but there is clearly a bug in the SSLEngine. It is tempting to file a bug, but it would be difficult for us to supply sample code sufficient enough for Sun to reproduce, short of deilvering our whole application...so I guess I'm just getting this out there in case someone has an "a-ha".

Similar Messages

  • Someone please review...Is this a bug in SSLEngine?

    I have been dealing with this for days and finally wrote a JUnit test just against the SSLEngine itself. I am about to file a bug report, but can someone please verify that they are having the same problem.
    Basically, on a rehanshake, just after a Runnable is retrieved and before it is run, the SSLEngine will not unwrap data. Here is an excerpt from the unit test....
              result = server.unwrap(encPacket, unencrPacket);
              assertEquals(HandshakeStatus.NEED_TASK, result.getHandshakeStatus());
              assertEquals(Status.OK, result.getStatus());     
              r = serverEngine.getDelegatedTask(); //get task but don't run it yet...wait until after decrypt of real data
              ByteBuffer dataOut = ByteBuffer.allocate(server.getSession().getApplicationBufferSize());
              dataOut.clear();
              helper.doneFillingBuffer(encData);
              log.fine("datain1="+encData+" out="+dataOut);
              result = serverEngine.unwrap(encData, dataOut);
              log.fine("datain2="+encData+" out="+dataOut);
              assertEquals(HandshakeStatus.NEED_TASK, result.getHandshakeStatus());
              assertEquals(Status.OK, result.getStatus());
    FINE: datain1=java.nio.HeapByteBuffer[pos=0 lim=37 cap=16665] out=java.nio.HeapByteBuffer[pos=0 lim=16384 cap=16384]
    Jul 4, 2005 3:45:50 PM biz.xsoftware.impl.nio.secure.test.TestNewAsynchSSLEngine testRawSSLEngine
    FINE: datain2=java.nio.HeapByteBuffer[pos=0 lim=37 cap=16665] out=java.nio.HeapByteBuffer[pos=0 lim=16384 cap=16384]Notice the status of the engine is still status=OK and handshake=NEED_TASK after trying to read the data that came in after the Runnable was retrieved. The log statements log that the encData was not even read from and the dataOut was not read to. Here are the logs proving that encData and dataOut wasn't touched at all.......
    FINE: datain1=java.nio.HeapByteBuffer[pos=0 lim=37 cap=16665] out=java.nio.HeapByteBuffer[pos=0 lim=16384 cap=16384]
    Jul 4, 2005 3:45:50 PM biz.xsoftware.impl.nio.secure.test.TestNewAsynchSSLEngine testRawSSLEngine
    FINE: datain2=java.nio.HeapByteBuffer[pos=0 lim=37 cap=16665] out=java.nio.HeapByteBuffer[pos=0 lim=16384 cap=16384]This may be "by design" such that data backs up until the Runnable is run which in myopinion is slightly dangerous.
    Full code of JUnit test(not real implementation code, just reproduction of problem with SSLEngine unit test) can be found at
    http://forum.java.sun.com/thread.jspa?threadID=641529&tstart=0
    thanks,
    dean

    actually, I was thinking the status after trying to
    unwrap my application data would have been...
    handShakeState = NEED_TASK (since Runnable hadn't
    been run yet).
    status = BUFFER_UNDERFLOW or OK(depending on if the
    application data had been decrypted or the engine
    needed more data to decrypt the packet)
    It seemed they had enough status to handle this
    situation to me but I could be missing something else.You are right about this: I was thinking more about the internal SSLEngine state-machine states, if it really is a state machine. So, I have now had a look and there is an internal RENEGOTIATE state which is supposed to allow concurrent data and re-handshake, and from a very quick look at Sun's code this should work for both input and output of app data during renegotiation, so I am going to have another look at your code ...
    One thing, the engine won't receive data in between the 2nd-last and the last WRAP of a re-handshake: this would be a TLS protocol violation (the Finished message must immediately follow the change_cipher_spec message).
    I also found the following comment in the output code which I will risk Sun's wrath by quoting:
         * If we have a task outstanding, this MUST be done before
         * doing any more wrapping, because we could be in the middle
         * of receiving a handshake message, for example, a finished
         * message which would change the ciphers.
         */

  • Potential concurrency bug in OC4J 10.0.3 WebServices TestPageProvider

    Hi,
    I was wondering whether anybody else was having problems with the OC4J 10.0.3 preview when placed under a light load of concurrent users.
    We have downloaded the JAX-RPC stateless Web service WebServices sample from http://www.oracle.com/technology/tech/java/oc4j/1003/how_to/how-to-ws.html and placed it under varying loads using LoadRunner, when we run a single user over 100 iterations there is no problem but when we invoke 3+ users against the webservice testpage we get random HTTP 500 Internal Server errors, the exact message is :
    =h= Received 2692 bytes from server
    <HTML><HEAD><TITLE>500 Internal Server Error</TITLE></HEAD><BODY><H1>500 Internal Server Error</H1><PRE>java.lang.ArrayIndexOutOfBoundsException
    at java.lang.System.arraycopy(Native Method)
    at oracle.security.jazn.util.SecureRandom.engineNextBytes(Unknown Source)
    at oracle.security.jazn.util.SecureRandom.nextBytes(Unknown Source)
    at oracle.j2ee.util.UUID.<init>(UUID.java:59)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.EvermindHttpSession.encodeSession(EvermindHttpSession.java:484)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.HttpApplication.createSession(HttpApplication.java:1586)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.EvermindHttpServletRequest.getSession(EvermindHttpServletRequest.java:2441)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.EvermindHttpServletRequest.getSession(EvermindHttpServletRequest.java:2341)
    at oracle.j2ee.ws.server.TestPageProvider.doInvokeService(TestPageProvider.java:621)
    at oracle.j2ee.ws.server.TestPageProvider.doPage(TestPageProvider.java:149)
    at oracle.j2ee.ws.server.JAXRPCServlet.doGet(JAXRPCServlet.java:585)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:771)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:298)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:829)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
    at com.evermind[Oracle Application Server Containers for J2EE 10g (10.0.3.0.0) - Developer Preview].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:291)
    at java.lang.Thread.run(Thread.java:534)
    It seems to us that there is a concurreny bug that is showing up when some kind of a session identifier is being assigned to each incoming request. Note that the webservice itself is marked as stateless and we are testing at the moment to prove that when the service is stateful the problem does not exist.
    I know that this is not the ideal way of invoking the webservice since it doesn't actually exercise the soap engine on submission but it may be a little bug worth looking into.
    Regards,
    pj.

    Hi,
    Are you trying to do Load testing with 10gApp Server? We have to do this too. Can you tell me if there is any documentation for this Load Testing for 10gAppserver . Or if yo have done can you tell me how to start doing this please. If you don't have a problem.
    Your help will be greatly appreciated.
    Thanks,
    Asha

  • SSLEngine closing prematurely on SSLHandshakeException?

    I have worked with the SSLEngine using non-blocked IO and it mostly works.
    I do have a problem when a client connects and I get
    WorkerThread-1, fatal error: 40: no cipher suites in common
    javax.net.ssl.SSLHandshakeException: no cipher suites in common
    WorkerThread-1, SEND TLSv1 ALERT:  fatal, description = handshake_failure
    WorkerThread-1, WRITE: TLSv1 Alert, length = 2in a delegate task. The handshake status is NEED_WRAP after this but when
    I call wrapHandshake I get
    WorkerThread-1, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in commonwhich means I'm not able to send the error reply to the connected client.
    Is this a bug in SSLEngine or simply a misunderstanding on my part on what's going on.
    I'm thankful for any insight on this.
    regards
    /Magnus Hulth�n

    Thanks,
    Yes that would make sense, and that is how I would expect it to work.
    The problem is that when call wrap (not wrapHandshake as I mistakenly wrote in my previous post) I get the exception
    WorkerThread-1, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in commonJust to see if there was some timing issue involved I tried to call wrap immediately after the delegated task finished and still got the same exception.
    What it looks like to me is that the engine needs to wrap the error message but is already closed by the handshake error and therefore not able to actually perform the wrap.

  • Concurrency on iOS

    Is concurrency available yet for AIR apps targeted for iOS? I couldn't seem to find a definitive and current answer.

    A message from Chris Campbell stated on Dec 9:
    "AIR developers, we haven’t forgotten about you!  It’s been all hands on deck getting support into AIR for iOS 64 bit.  Our plan is to shortly (possibly later this week) release an updated AIR 16 beta with iOS 64-bit compatibility along with an early peek at the videoTexture API for iOS.  We’re counting on getting great feedback from you and quickly making improvements.  We’ll continue updating our beta releases on labs.adobe.com to make sure you have the latest code available.  We know its going to be tough for everyone as we approach this holiday season, but we’re committed to making sure we have a solution in place before Apple changes their store requirements."
    Chris has indicated that 64-bit support for iOS is top priority. In order for 64-bit support to happen the new iOS compiler must be finished, they are close but not completely done yet. The VideoTexture appears to be the next priority since it is already in beta for Windows, Mac. Adobe still has not finalized VideoTexture on Windows nor Mac, but I would imagine that they are close to getting that right since Chris said they will have a preview of VideoTexture on iOS in January. Adobe still has many bugs with concurrency, such us the MessageChannel not push popping the message queue correctly, making it unstable on Windows, Mac, and Android. To fix the Windows and Android concurrency bugs alone I would imagine will take at least a month. To finalize VideoTexture will take another month for Windows alone, and another month for Android since Android suffers from dozens of H.264 video bugs. Adobe still is working on support for Android 5.0.1 and has not yet finished that work either. So I would not expect concurrency on iOS to be released until June or later.
    But we are sure hoping that it is sooner!

  • Obtaining principal in EJB helper classes

    I have a pretty typical EJB setup where the actual EJBs delegate a lot of work
    off to helper classes which are simple java classes. Some of these helpers need
    access to the principal currently executing on this container thread. Currently,
    I am passing the principal as a parameter in every method signature on the helpers
    which need it. But as you can probably guess that approach is quickly becoming
    unweildy.
    Ideally, what I would like to do is to have access to the principal associated
    with the currently executing thread. I can mimic this by setting thread-local
    variables in the EJB prior to calling helpers. But I was wondering (ok, hoping)
    that there was already a way to access this information (either through weblogic
    classes or MBeans). At this point, I dont even care if it is not portable.
    P.S., I use WL6.1
    Thank you in advance,
    Steve

    >
    The helper methods do database querries etc and return results that the EJB sends onwards to clients. If these methods
    are NOT synchronized (and the ejbs share the static class) won't it cause concurrency errors? I think most of our methods are not
    synchronized (and it doesn't seem to cause any concurrency errors so far... though the system have not beeen stressed test that much,
    and concurrency bugs tends to pop up later and randomly :P).
    >
    No, if you dont have any static data variables in the Java classes, static method as such will not cause concurrency errors, and the methods should not be synchronized.
    If you have any synchronized methods and they take a while to execute, that could become a bottleneck in itself, because different threads waiting for each other,
    so make sure you dont have any synchronized methods where it is not explicitly needed.
    Think of a static method (without static data in the class being manipulated) as a plain function in another programming-language.
    >
    We have some scaleability problems with the EJBs... It seems as if they do not run concurrently. If we do a stress test with several threads calling the EJBs their response time increases by a too large factor to feel comfortable...
    >
    Apparently, you do have a some scaling/concurrency problem, which could have many causes -- transaction locking and clashes in the database, poorly configured database, network congestion, problems in the EJB architecture, etc -- can be many reasons...
    The general idea to debug, is first to find out exactly what calls in your code that take longest time to execute (profiling, logging, System.out.println's are useful) when you put parallel load on your system -- rather than just seeing "the whole application seems slow" -- from there you can move on, "divide&conquer" the problem, etc...

  • 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

  • EJB environment question (static helper classes)

    We're using JBoss as AS containing several stateless session beans.
    Now, we have certain helper classes that are abstract and contain static methods. Is this a problem for the EJBs? All of them use these helper classes all over their methods. Are they sharing the static class and will slow down somehow? Or is each EJB using its version of the class and can run concurrently?
    Should we rethink this and put an INSTANCE of each helper class in each ejb instead of using static methods in the helper class?
    Now in EJB method:
    Helper.calculateStuff();
    Should it be?
    Helper h = new Helper(); // defined when ejb is created
    helper.calculateStuff();
    Edited by: JAeon on Sep 8, 2008 12:21 AM
    Edited by: JAeon on Sep 8, 2008 12:22 AM

    >
    The helper methods do database querries etc and return results that the EJB sends onwards to clients. If these methods
    are NOT synchronized (and the ejbs share the static class) won't it cause concurrency errors? I think most of our methods are not
    synchronized (and it doesn't seem to cause any concurrency errors so far... though the system have not beeen stressed test that much,
    and concurrency bugs tends to pop up later and randomly :P).
    >
    No, if you dont have any static data variables in the Java classes, static method as such will not cause concurrency errors, and the methods should not be synchronized.
    If you have any synchronized methods and they take a while to execute, that could become a bottleneck in itself, because different threads waiting for each other,
    so make sure you dont have any synchronized methods where it is not explicitly needed.
    Think of a static method (without static data in the class being manipulated) as a plain function in another programming-language.
    >
    We have some scaleability problems with the EJBs... It seems as if they do not run concurrently. If we do a stress test with several threads calling the EJBs their response time increases by a too large factor to feel comfortable...
    >
    Apparently, you do have a some scaling/concurrency problem, which could have many causes -- transaction locking and clashes in the database, poorly configured database, network congestion, problems in the EJB architecture, etc -- can be many reasons...
    The general idea to debug, is first to find out exactly what calls in your code that take longest time to execute (profiling, logging, System.out.println's are useful) when you put parallel load on your system -- rather than just seeing "the whole application seems slow" -- from there you can move on, "divide&conquer" the problem, etc...

  • Importing from iPhone _LOST_ pictures

    I imported photos from my iPhone, then chose to delete the original photos. At the same time I clicked this button, a text message came in to my phone and apparently triggered a concurrency bug. iPhoto completely beach-balled and didn't come back after waiting 5 minutes. I had to force-quit iPhoto. After relaunching, I found half the photos on my iPhone were deleted, and the import never made it to disk. My photos were gone.
    Two apparent bugs conspired against me to loose the photos:
    1) after importing but before asking the user what to do with the originals, the database is not synced (BAD bug)
    2) the iPhone has a race condition when receiving text messages and dealing with iPhoto
    Use with caution.

    Well the horses are out of the barn but some thoughts on your experience.
    1 - it's much safer to use Image Capture to upload the photos to a folder on the Desktop first (assuming Image Capture can recognize and upload from an iPhone).
    2 - having iPhoto do the deleting has never been a good idea exactly for the reason you experienced. The same goes for importing from cameras.
    I don't know if you can set the iPHoto to show up on the desktop like external media. If you can you can use software like MediaRECOVER to recover the deleted photos from the memory card in the iPhone. I don't have one so am only guessing here. This works for cameras that had their photos deleted by iPhoto and lost.
    This won't help you with your current photos but, if it works, may help others.
    Happy New Year

  • CheckThread static analysis tool, @ThreadSafe, @ThreadConfined

    Hello,
    I'm looking for feedback on CheckThread, a free and open source static analysis tool I created.
    By using a @ThreadConfined and @ThreadSafe annotation on methods and classes, this tool can catch certain types of threading bugs at compile time.
    To see examples, check out:
    http://www.checkthread.org/examples.html
    For example, when developing a Java Swing app, a Java developer must ensure that the Swing component is accessed only on the Event-Dispatch Thread after the component is realized. With large applications that are thousands of lines of code, simple thread confinement for Swing can be difficult to enforce and may result in wacky sporadic runtime behavior. CheckThread solves this problem using annotations and a static analysis Ant task - thread confinement problems are caught at compile time. An added benefit is that the threading model of Java code is well documented inline with the code.
    All feedback welcome!
    Thanks,
    Joe

    I recommend you to ask developers of FindBugs to add your feature to their project. FindBugs says that it already supports concurrency bugs finding (see jcip package), but that support is very poor (actually, it's not working). I'll try your program.

  • IndexOutOfBoundsException in deamon thread

    Today on on of our internal builds I am getting these exceptions. My first thought is data corruption in a specific log file. If so how do I go about finding which logfile is corrupt? This is not bad the data will be regenerated tomorrow any way. And access to most of the data in the bdb/je seems ok. Actually I have not been able to find an corrupt record.
    Regards,
    Jerven
    <DaemonThread name="Checkpointer (BDB/je at uniprot)"/> caught exception: java.lang.IndexOutOfBoundsException
    java.lang.IndexOutOfBoundsException
    at com.sleepycat.bind.tuple.TupleInput.readBoolean(TupleInput.java:186)
    at com.sleepycat.je.cleaner.PackedObsoleteInfo.countObsoleteInfo(PackedObsoleteInfo.java:60)
    at com.sleepycat.je.log.LogManager.serialLogInternal(LogManager.java:671)
    at com.sleepycat.je.log.SyncedLogManager.serialLog(SyncedLogManager.java:40)
    at com.sleepycat.je.log.LogManager.multiLog(LogManager.java:388)
    at com.sleepycat.je.recovery.Checkpointer.logSiblings(Checkpointer.java:1285)
    at com.sleepycat.je.recovery.Checkpointer.flushIN(Checkpointer.java:970)
    at com.sleepycat.je.recovery.Checkpointer.flushDirtyNodes(Checkpointer.java:709)
    at com.sleepycat.je.recovery.Checkpointer.doCheckpoint(Checkpointer.java:476)
    at com.sleepycat.je.recovery.Checkpointer.onWakeup(Checkpointer.java:266)
    at com.sleepycat.je.utilint.DaemonThread.run(DaemonThread.java:161)
    at java.lang.Thread.run(Thread.java:619)

    I've been looking at this and my preliminary conclusion is that it is a rare concurrency bug in JE, it has been in existence for quite a while, but it has not been previously reported. It is not a persistent problem (no corruption or invalid data is stored), but once it occurs in an open Environment it will occur repeatedly -- at each checkpoint and perhaps during cache eviction. When the Environment is closed and reopened, checkpoints and eviction should then work normally, and no permanent damage will have been done.
    It will take some time to reproduce this in a unit test and fix it. We will do that, and we'll be sure to resolve this before the next patch release. In the mean time, I suggest that you consider this to be an extremely rare occurrence and unlikely to occur again.
    If you are seeing this repeatedly after shutting down the environment, then please let me know -- this would mean that my diagnosis is incorrect.
    Thanks,
    --mark                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

  • Quicktime with browser

    Well I go to the quicktime website with IE7 and I get an error that says something. When I go with Firefox2, the software crashes. Does anyone else have this problem? I wanna reinstall it, but I installed with quciktime and iTunes. How can I install Quciktime only? Any solutions without reinstalling Quciktime?

    Concurrency bugs (i.e. bugs in multi-threaded code) are a typical cause of non-deterministic behaviour since the manifestation of the bug is dependent upon the timing of context switches between threads and context switches are unpredictable with a pre-emptive threading model. I have observed behaviour that is strongly suggestive of a concurrency bug while using QuickTime 7.1.3 as a browser plugin on Mac OS X.
    Since concurrency bugs are inherently difficult to reproduce, it is easy for developers, or their managers, to deny the existence of such a bug. Just because they can't reproduce it easily doesn't mean that it doesn't exist!

  • Explanation for exception?

    Hello,
    I am receiving the following exception periodically, normally after a number of successful inserts. For no obvious reason an insert to the large container (3.5GB) fails with the following exception
    transaction has active cursors
    PANIC: Invalid argument
    PANIC: fatal region error detected; run recovery
    XmlException 0, Error: Could not fetch next DOM element for doc id: 2242, nid: 1.0F
    After I do a recovery everything works fine for a while before I get the same.
    Any ideas?

    Hi George,
    Thanks for the response. I continued to have issues with the one container. On attempting to reindex with no other applications accessing the container the dbxml shell would segfault. I managed to extract an acceptable amount of data and then created a new container. I have not seen the problem again since I recreated the container.
    While I certainly think its possible there's a concurrency bug in my app the resolution by recreation of the container to me indicates I had corruption of some sort. The container itself is fairly old and was also used with dbxml 2.3. Previous application (using 2.3) bugs certainly have caused corruption as I had a number of problems with node names missing in documents after updatnig to 2.6 and reindexing.

  • [svn] 1043: Bug: LCDS-184 - Concurrent modification exception thrown during remote subscription management

    Revision: 1043
    Author: [email protected]
    Date: 2008-03-31 15:22:13 -0700 (Mon, 31 Mar 2008)
    Log Message:
    Bug: LCDS-184 - Concurrent modification exception thrown during remote subscription management
    QA: Yes
    Doc: No
    Details:
    Make the 'subscriptions' set in MessageClient/RemoteMessageClient concurrent modification safe.
    Ticket Links:
    http://bugs.adobe.com/jira/browse/LCDS-184
    Modified Paths:
    blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/services/messaging/RemoteMess ageClient.java

  • [svn] 1044: Bug: LCDS-184 - Concurrent modification exception thrown during remote subscription management

    Revision: 1044
    Author: [email protected]
    Date: 2008-03-31 15:23:07 -0700 (Mon, 31 Mar 2008)
    Log Message:
    Bug: LCDS-184 - Concurrent modification exception thrown during remote subscription management
    QA: Yes
    Doc: No
    Details:
    Make the 'subscriptions' set in MessageClient/RemoteMessageClient concurrent modification safe.
    Ticket Links:
    http://bugs.adobe.com/jira/browse/LCDS-184
    Modified Paths:
    blazeds/branches/3.0.x/modules/core/src/java/flex/messaging/MessageClient.java

Maybe you are looking for