Filed the JIRA. Actually, I was able to get Eclipselink 2 working on Glassfish 2, but I still hit this error. I haven't done heavy load testing with Glassfish 3, I will try it when I have some time and update the JIRA.
The exception hits when the app is iterating the comments in getSocialEvent. Haven't been able to figure out the cause. -----Original Message----- From: Shanti Subramanyam [mailto:[email protected]] Sent: Saturday, April 03, 2010 9:37 AM To: [email protected] Subject: Re: Eclipselink bug James, Can you please file one or more JIRA's on this (if it hasn't been done already) ? You said earlier that the latest version of Eclipselink doesn't work with glassfish v2. Have you tried glassfish v3 ? Since JPA is still relatively new (I know, I know ... but 'new' in the Java EE world is different than in the web world), there are bound to be such problems under load. I am a little puzzled by your issue though - as far as I know, the workload driver does not modify comments in any way. They are only retrieved in EventDetail (you can check the driver code in src/org/apache/olio/workload/driver/UIDriver.java). Kim/Akara - do you have any better insight into this issue ? Shanti On Thu, Feb 25, 2010 at 12:01 PM, James Zubb <[email protected]> wrote: > just an update. > > There seems to be some sort of race condition going on with the > comments on events. I added an exception handler to the getComment > section of line 583 of ModelFacade.java and found it crash again at > line 909. I am adding exception handling as I go. > > Not sure exactly what is happening. Possibly a comment is deleted by > one thread while it is trying to be read by another? > > Any thoughts? > > > > -----Original Message----- > From: James Zubb [mailto:[email protected]] > Sent: Friday, February 19, 2010 10:34 AM > To: [email protected] > Subject: RE: Eclipselink bug > > 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.p > ersistence.session.file:/opt/glassfish/domains/domain1/applications/j2 > ee-modules/webapp/WEB-INF/classes/-BPWebappPu|_ThreadID=16;_ThreadName > =httpSSLWorkerThread-8080-0;_RequestID=57c0781d-255f-4f9e-9ccf-41a5c29 > 6befe;| > 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(SSLWo > rkerThread.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 > > > >
