Okay but what approach are you taking currently? Is this an attempt to back port the transaction management changes or are you updating OFBiz to a recent revision?
Regards Scott On 27/01/2010, at 1:37 PM, Florin Popa wrote: > Hi, > > There were a lot of changes done... but nothing inside the core of the > project as well as nothing related to the DB layer.. > > I start 90 concurrent users, they all perform well for a while, aprox 10 mins > with a single Ofbiz instance (in production I have 2 instances with an apache > ballancer) and then suddenly I got those errors.. I rechecked and this one is > the first one and appears often.. > > 2010-01-27 15:04:44,384 (TP-Processor110) > [InheritableTransactionContext.java:311:ERROR] Unable to roll back transaction > java.lang.IllegalStateException: Status is STATUS_NO_TRANSACTION > at > org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:438) > > at > org.apache.geronimo.transaction.context.InheritableTransactionContext.rollbackAndThrow(InheritableTransactionContext.java:308) > > at > org.apache.geronimo.transaction.context.InheritableTransactionContext.complete(InheritableTransactionContext.java:199) > > at > org.apache.geronimo.transaction.context.InheritableTransactionContext.commit(InheritableTransactionContext.java:146) > > at > org.apache.geronimo.transaction.context.GeronimoTransactionManager.commit(GeronimoTransactionManager.java:81) > > at > org.ofbiz.entity.transaction.TransactionUtil.commit(TransactionUtil.java:192) > at > org.ofbiz.entity.transaction.TransactionUtil.commit(TransactionUtil.java:178) > at > org.ofbiz.widget.screen.ModelScreen.renderScreenString(ModelScreen.java:163) > at org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:105) > at org.ofbiz.widget.screen.ScreenRenderer.render(ScreenRenderer.java:90) > at > org.ofbiz.widget.screen.ScreenWidgetViewHandler.render(ScreenWidgetViewHandler.java:78) > > at > org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:699) > at > org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:467) > at org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:200) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) > > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) > > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) > > at > org.tuckey.web.filters.urlrewrite.RewrittenUrl.doRewrite(RewrittenUrl.java:176) > > at > org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:728) > > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > > at > org.ofbiz.webapp.control.ContextFilter.doFilter(ContextFilter.java:423) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > > > After a while there is no chance to access the DB and nothing works at all > > thanks, > Florin >> Sorry for the slow reply Florin, this slipped past me until I saw your >> message to Jacques a moment ago. >> >> Could you provide more details about what changes you've made to this >> checkout? My first guess is that there's something wrong with the database >> connection since the problem appears during the first attempt to connect to >> it. >> >> Regards >> Scott >> >> HotWax Media >> http://www.hotwaxmedia.com >> >> On 25/01/2010, at 7:35 AM, Florin Popa wrote: >> >> >>> Hello Scott, >>> >>> Additionally, I just noticed that revision 902810 could not be started: >>> >>> [java] 2010-01-25 15:12:48,825 (main) [ ModelViewEntity.java:529:WARN ] >>> Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> statusDelay of view-entity ExampleStatusDetail >>> >>> [java] 2010-01-25 15:12:48,933 (main) [ ModelViewEntity.java:529:WARN >>> ] Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> quantityOrdered of view-entity OrderItemQuantityReportGroupByItem >>> >>> [java] 2010-01-25 15:12:48,934 (main) [ ModelViewEntity.java:529:WARN >>> ] Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> quantityOpen of view-entity OrderItemQuantityReportGroupByItem >>> >>> [java] 2010-01-25 15:12:48,934 (main) [ ModelViewEntity.java:529:WARN >>> ] Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> quantityOrdered of view-entity OrderItemQuantityReportGroupByProduct >>> >>> [java] 2010-01-25 15:12:48,934 (main) [ ModelViewEntity.java:529:WARN >>> ] Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> quantityOpen of view-entity OrderItemQuantityReportGroupByProduct >>> >>> [java] 2010-01-25 15:12:48,947 (main) [ ModelViewEntity.java:529:WARN >>> ] Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> quantityOrdered of view-entity OrderItemAndShipGrpInvResAndItemSum >>> >>> [java] 2010-01-25 15:12:48,947 (main) [ ModelViewEntity.java:529:WARN >>> ] Conversion for complex-alias needs to be implemented for cache and >>> in-memory eval stuff to work correctly, will not work for alias: >>> totQuantityAvailable of view-entity OrderItemAndShipGrpInvResAndItemSum >>> >>> [java] 2010-01-25 15:12:49,056 (main) [ ModelReader.java:389:INFO >>> ] FINISHED LOADING ENTITIES - ALL FILES; >>> >>> #Entities=839 #ViewEntities=263 #Fields=8747 #Relationships=2903 >>> >>> #AutoRelationships=2138 >>> >>> [java] 2010-01-25 15:12:49,068 (main) [ GenericDelegator.java:232:INFO >>> ] Doing entity definition check... >>> >>> [java] 2010-01-25 15:12:49,072 (main) [ ModelEntityChecker.java:501:INFO >>> ] [initReservedWords] array length=1023 >>> >>> [java] Exception in thread "main" java.lang.NullPointerException >>> >>> [java] at >>> >>> org.ofbiz.entity.GenericDelegator.getEntityFieldType(GenericDelegator.java:484) >>> >>> [java] at >>> >>> org.ofbiz.entity.model.ModelEntityChecker.checkEntities(ModelEntityChecker.java:101) >>> >>> [java] at >>> >>> org.ofbiz.entity.GenericDelegator.<init>(GenericDelegator.java:233) >>> >>> [java] at >>> >>> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:43) >>> >>> [java] at >>> >>> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25) >>> >>> [java] at >>> >>> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:181) >>> >>> [java] at >>> >>> org.ofbiz.entity.DelegatorFactory.getDelegator(DelegatorFactory.java:31) >>> >>> [java] at >>> >>> org.ofbiz.entityext.data.EntityDataLoadContainer.start(EntityDataLoadContainer.java:229) >>> >>> [java] at >>> >>> org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:100) >>> >>> [java] at >>> >>> org.ofbiz.base.start.Start.startStartLoaders(Start.java:272) >>> >>> [java] at org.ofbiz.base.start.Start.startServer(Start.java:322) >>> >>> [java] at org.ofbiz.base.start.Start.start(Start.java:326) >>> >>> [java] at org.ofbiz.base.start.Start.main(Start.java:411) >>> >>> [java] 2010-01-25 15:12:49,176 (OFBiz_Shutdown_Hook) [ >>> ContainerLoader.java:113:INFO ] Shutting down containers >>> >>> [java] Java Result: 1 >>> >>> >>> BUILD SUCCESSFUL >>> >>> Total time: 8 seconds >>> >>> >>> >>> >>> Can you help please? >>> >>> thanks, >>> Flopa >>> >>>> Given the amount of changes required to back port you're probably better >>>> to upgrade to a newer revision, depending on how you've handled your >>>> custom code and what tests you have in place to verify your main areas of >>>> functionality, it should be relatively straightforward. >>>> >>>> Regards >>>> Scott >>>> >>>> HotWax Media >>>> http://www.hotwaxmedia.com >>>> >>>> On 25/01/2010, at 7:01 AM, Florin Popa wrote: >>>> >>>> >>>>> Hello all, >>>>> >>>>> >>>>> We started to develop an e-commerce application based on Ofbiz framework >>>>> around 2 years ago. >>>>> The version we started from is a revision 691692. >>>>> >>>>> Main problem is that we already have few systems launched into >>>>> production, based on that revision. >>>>> >>>>> Meanwhile, doing some mass tests, we encountered a lot of problems - >>>>> mostly related to transactions... >>>>> We noticed the implementation of >>>>> /framework/entity/src/org/ofbiz/entity/transaction/TransactionUtil.java >>>>> has lots of problems from this point of view - maybe not thread safe. >>>>> >>>>> We just checked out today revision 902810 and it seems someone really >>>>> improved a lot that source code from threads-safe point of view. >>>>> Trying to upgrade only that class into our old version drove to upgrade >>>>> for more and more classes. We encountered lots of incompatibilities - the >>>>> source code has been in some places fully changed. Right now, having more >>>>> than 800 compilation errors I would not feel too optimist to integrate >>>>> only what I need from the newer version into the old one. >>>>> >>>>> On the other hand, trying to get 902810 and then put over our work might >>>>> also cause same problems because the entity layer and conditions handling >>>>> seems to be changed.. I even expect to be worse that way because maybe >>>>> web templates are also changed. >>>>> >>>>> Which way could someone suggest to proceed for a better version where all >>>>> database/entity layer/transaction later problems are fixed? >>>>> >>>>> >>>>> Many thanks, >>>>> Flopa >>>>> >>>> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
