Thanks. I am running virtualized under CentOS. I have been running into some
issues where Eclipse will throw a concurrency exception under heavy load, just
wondering if this is the same error you were seeing:
[#|2010-02-10T16:15:10.003-0800|WARNING|sun-appserver2.1|org.eclipse.persistence.session.file:/opt/glassfish/domains/domain1/applications/j2ee-modules/webapp/WEB-INF/classes/-BPWebappPu|_ThreadID=16;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=57c0781d-255f-4f9e-9ccf-41a5c296befe;|
Local Exception Stack:
Exception [EclipseLink-2004] (Eclipse Persistence Services -
1.1.3.v20091002-r5404): org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: A signal was attempted before wait() on
ConcurrencyManager. This normally means that an attempt was made to
commit or rollback a transaction before it was started, or to rollback a
transaction twice.
at
org.eclipse.persistence.exceptions.ConcurrencyException.signalAttemptedBeforeWait(ConcurrencyException.java:84)
at
org.eclipse.persistence.internal.helper.ConcurrencyManager.releaseReadLock(ConcurrencyManager.java:478)
at
org.eclipse.persistence.internal.identitymaps.CacheKey.releaseReadLock(CacheKey.java:433)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:939)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.cloneAndRegisterObject(UnitOfWorkImpl.java:833)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor.getAndCloneCacheKeyFromParent(UnitOfWorkIdentityMapAccessor.java:171)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkIdentityMapAccessor.getFromIdentityMap(UnitOfWorkIdentityMapAccessor.java:110)
at
org.eclipse.persistence.internal.sessions.IdentityMapAccessor.getFromIdentityMap(IdentityMapAccessor.java:327)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3776)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3736)
at
org.eclipse.persistence.queries.ObjectBuildingQuery.registerIndividualResult(ObjectBuildingQuery.java:362)
at
org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneNormally(ObjectBuilder.java:582)
at
org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:544)
at
org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:485)
at
org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:437)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:569)
at
org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:904)
at
org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:490)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:928)
at
org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:664)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:889)
at
org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:458)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:952)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2750)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1181)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1165)
at
org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:81)
at
org.eclipse.persistence.internal.indirection.QueryBasedValueHolder.instantiate(QueryBasedValueHolder.java:71)
at
org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
at
org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiateImpl(UnitOfWorkValueHolder.java:161)
at
org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder.instantiate(UnitOfWorkValueHolder.java:230)
at
org.eclipse.persistence.internal.indirection.DatabaseValueHolder.getValue(DatabaseValueHolder.java:83)
at
org.eclipse.persistence.indirection.IndirectList.buildDelegate(IndirectList.java:220)
at
org.eclipse.persistence.indirection.IndirectList.getDelegate(IndirectList.java:386)
at
org.eclipse.persistence.indirection.IndirectList$1.<init>(IndirectList.java:514)
at
org.eclipse.persistence.indirection.IndirectList.listIterator(IndirectList.java:513)
at
org.eclipse.persistence.indirection.IndirectList.iterator(IndirectList.java:477)
at
org.apache.olio.webapp.model.ModelFacade.getSocialEvent(ModelFacade.java:583)
at
org.apache.olio.webapp.controller.EventAction.process(EventAction.java:71)
at
org.apache.olio.webapp.controller.ControllerServlet.process(ControllerServlet.java:61)
at
org.apache.olio.webapp.controller.ControllerServlet.doGet(ControllerServlet.java:93)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:315)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:666)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:597)
at
com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:872)
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:264)
at
com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
|#]
Once this happens the olio app hangs, I can contact it but it never finishes
the request. Restarting the domain fixes it, but that is not workable in the
middle of a run.
I tried upgrading to eclipselink 2.0, but that didn't work OOTB on Glassfish
2.1.1.
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Friday, February 12, 2010 2:59 PM
To: [email protected]
Subject: Re: Eclipselink bug
Hi James,
I checked with one of the engineers who work on Eclipselink (and who was
originally helping us debug this problem) and he mentioned that there
was no effort to explicitly tried to analyze this exact problem.
However, he also mentioned that there has been a lot of work done to
improve behavior of EclipseLink under high concurrency.
I recall that we observed this issue on a Niagara platform, and when we
had reported this issue, they were unable to reproduce this issue but it
was not on the same hardware that we had.
I'm not sure what platform you are running your test on, but it may be
worth running your test after reducing the allocation size.
Unfortunately, I cannot test with with the original hardware that we had
when we discovered this issue because we had migrated away some time ago.
Kim
>
> Hi,
>
> There is mention of an Eclipselink bug in the source and the older docs for
> the Java app regarding duplicate sequence numbers being generated under heavy
> load. Are there any other details regarding this? I didn't find anything in
> Jira, looks like it has been in the code since the initial checkin. Has
> anyone tested removing the workarounds from the code yet?
>
> thanks,
>
> james
>
