RE: [JBoss-user] LOCKING-WAITING

[Mit.freundlichen.Gruessen.Markus.Cozowicz]

I have the problem too. (having a log file of 400mb)

will this fix be checked into cvs?

thx markus


-----Original Message-----
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Dienstag, 20. März 2001 21:14
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] LOCKING-WAITING


You're may be getting such a performance hit because of all the 
LOCKING-WAITING messages being sent to jboss/logs/server.log.  Check out

that file, my guess it will be very, very large.

BTW, please don't remove that message.  It is very useful for debugging 
purposes.

Here's a fix for that very problem,

in org.jboss.ejb.plugins.EntityInstanceInterceptor I changed the invoke 
method.

  public Object invoke(MethodInvocation mi)
  throws Exception
  {
      // The id store is a CacheKey in the case of Entity
      CacheKey key = (CacheKey)mi.getId();

      // Get cache
      AbstractInstanceCache cache = 
(AbstractInstanceCache)container.getInstanceCache();
      Sync mutex = (Sync)cache.getLock(key);

      EnterpriseContext ctx = null;

      try
      {
          boolean waitingOnTransaction = false; // So we don't output 
LOCKING-WAITING all the time
          boolean waitingOnContext = false; // So we don't output 
LOCKING-WAITING all the time

          do
          {
              if (mi.getTransaction() != null && 
mi.getTransaction().getStatus() == Status.STATUS_MARKED_ROLLBACK)
                  throw new RuntimeException("Transaction marked for 
rollback, possibly a timeout");

              try
              {

                  mutex.acquire();

                  // Get context
                  ctx = cache.get(key);

                  // Do we have a running transaction with the context
                  Transaction tx = ctx.getTransaction();
                  if (tx != null &&
                      // And are we trying to enter with another 
transaction
                      !tx.equals(mi.getTransaction()))
                  {
                      // Let's put the thread to sleep a lock release 
will wake the thread
                      // Possible deadlock
                      if (!waitingOnTransaction)
                      {
                          Logger.debug("LOCKING-WAITING (TRANSACTION) 
for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" tx:"+((tx == null) ? 
"null" : tx.toString()));
                          waitingOnTransaction = true;
                      }

                      // Try your luck again
                      ctx = null;
                      continue;
                  }
                  else
                  {
                      if (waitingOnTransaction)
                      {
                          Logger.debug("FINISHED-LOCKING-WAITING 
(TRANSACTION) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode()+" 
tx:"+((tx == null) ? "null" : tx.toString()));
                          waitingOnTransaction = false;
                      }
                      // If we get here it's the right tx, or no tx
                      if (!ctx.isLocked())
                      {
                          //take it!
                          ctx.lock();
                      }
                      else
                      {
                          if (!isCallAllowed(mi)) {

                              // Go to sleep and wait for the lock to be

released
                              // This is not one of the "home calls" so 
we need to wait for the lock

                              // Possible deadlock
                              if (!waitingOnContext) {
                                  Logger.debug("LOCKING-WAITING (CTX) 
for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
                                  waitingOnContext = true;
                              }

                              // Try your luck again
                              ctx = null;
                              continue;
                              // Not allowed reentrant call
                              //throw new RemoteException("Reentrant 
call");
                          }
                          else
                          {
                              if (waitingOnContext) {
                                  Logger.debug("FINISHED-LOCKING-WAITING

(CTX) for id "+ctx.getId()+" ctx.hash "+ctx.hashCode());
                                  waitingOnContext = false;
                              }
                              //We are in a home call so take the lock, 
take it!
                              ctx.lock();
                          }
                      }
                  }
              }
              catch (InterruptedException ignored) {}
              finally
              {
                  mutex.release();
              }

          } while (ctx == null);

          // Set context on the method invocation
          mi.setEnterpriseContext(ctx);

          // Go on, you won
          return getNext().invoke(mi);

      }
      catch (RemoteException e)
      {
          // Discard instance
          // EJB 1.1 spec 12.3.1
          cache.remove(key);

          throw e;
      } catch (RuntimeException e)
      {
          // Discard instance
          // EJB 1.1 spec 12.3.1
          cache.remove(key);

          throw e;
      } catch (Error e)
      {
          // Discard instance
          // EJB 1.1 spec 12.3.1
          cache.remove(key);

          throw e;
      } finally
      {
          // Logger.debug("Release instance for "+id);

          // ctx can be null if cache.get throws an Exception, for
          // example when activating a bean.
          if (ctx != null)
          {
              try
              {
                  mutex.acquire();

                  // unlock the context
                  ctx.unlock();

                  if (ctx.getId() == null)
                  {

                      // Work only if no transaction was encapsulating 
this remove()
                      if (ctx.getTransaction() == null)
                      {
                          // Here we arrive if the bean has been removed

and no
                          // transaction was associated with the remove,

or if
                          // the bean has been passivated

                          // Remove from cache
                          cache.remove(key);

                          // It has been removed -> send to the pool
                          container.getInstancePool().free(ctx);
                      }
                      else
                      {
                          // We want to remove the bean, but it has a Tx

associated with
                          // the remove() method. We remove it from the 
cache, to avoid
                          // that a successive insertion with same pk 
will break the
                          // cache. Anyway we don't free the context, 
since the tx must
                          // finish. The EnterpriseContext instance will

be GC and not
                          // recycled.
                          cache.remove(key);
                      }
                  }
                  else
                  {
                      // Yeah, do nothing
                  }
              }
              catch (InterruptedException ignored) {}
              finally
              {
                  mutex.release();
              }
          }
      }
  }

marc fleury wrote:

> it is not a deadlock it is normal synchronization...
> 
> we must change that message
> 
> marc
> 
> 
> |-----Original Message-----
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Dragan
Milic
> |Sent: Tuesday, March 20, 2001 1:05 PM
> |To: [EMAIL PROTECTED]
> |Subject: [JBoss-user] LOCKING-WAITING
> |
> |
> |Hello,
> |
> |i'm experiencing performance problems with jboss 2.1 under solaris:
> |when i'm using one BMP EJB cuncurrently from multiple threads it
seems to
> |deadlock for a couple of seconds with following line reapeating in
> |server.log:
> |
> |[Category] LOCKING-WAITING (CTX) for id 
> |CategoryPK(MUIKAQJkw34AAADfZiTtGJvA,de_DE) ctx.hash 6877805
> |
> |cpu usage is 100% but calls to getXXX methods for that bean do not
return
> |untill deadlock is resolved (it takes usually 2-10 secs for that) and
> |after that everything seems to be fine untill next deadlock occurs -
bean
> |has Supports flag for transactions and ist not in a transaction
context
> |while using, so i don't thing that the whole happends because of
isolation
> |of transactions.
> |
> |Dragan.
> |
> |
> |
> |
> |
> |_______________________________________________
> |JBoss-user mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-user
> 
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
> 
> 
> 



_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user