Any chance for an upgrade? - help please

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Any chance for an upgrade? - help please

Florin Popa
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
Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Scott Gray-2
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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
We have a separate Eclipse project which contains ONLY the resources we
ever touched. But even like this no one of the procedures seems easy for
the moment

regards,
 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
>>    
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Jacques Le Roux
Administrator
If you are mostly interested by the framework fixes, you may try to apply the patches you may found in respective Jira issues...

Jacques

From: "Florin Popa" <[hidden email]>

> We have a separate Eclipse project which contains ONLY the resources we
> ever touched. But even like this no one of the procedures seems easy for
> the moment
>
> regards,
> 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
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
In reply to this post by Scott Gray-2
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
>>    
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
In reply to this post by Jacques Le Roux
I am not quite sure if a JIRA with exactly my non thread-safe issue
could be found.. so I started with the target to upgrade that class and
all related..but those related drove us further to more and more - at
least for the moment it seems no chance that way

thanks,
 Flopa

> If you are mostly interested by the framework fixes, you may try to
> apply the patches you may found in respective Jira issues...
>
> Jacques
>
> From: "Florin Popa" <[hidden email]>
>> We have a separate Eclipse project which contains ONLY the resources we
>> ever touched. But even like this no one of the procedures seems easy for
>> the moment
>>
>> regards,
>> 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
>>>>
>>>
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
In reply to this post by Jacques Le Roux
Hello Jacques,

Please let me know how can I find such patches in Jira for
TransactionUtil.java..it seems the work to upgrade is much bigger

My exception is almost always like

2010-01-27 15:04:39,691 (TP-Processor21)
[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)
                                                                                         


or like

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)
                                                                                               



Indeed it happens while I do mass tests using an automated tool - aprox
90 concurrent virtual users trying to show the products of a selected
tre category.





> If you are mostly interested by the framework fixes, you may try to
> apply the patches you may found in respective Jira issues...
>
> Jacques
>
> From: "Florin Popa" <[hidden email]>
>> We have a separate Eclipse project which contains ONLY the resources we
>> ever touched. But even like this no one of the procedures seems easy for
>> the moment
>>
>> regards,
>> 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
>>>>
>>>
>>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Scott Gray-2
In reply to this post by Florin Popa
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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
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
>>>>    
>>>>        
>>>  
>>>      
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Scott Gray-2
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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
In reply to this post by Scott Gray-2
Hello Scott,

I am trying again to me more coherent - difficult in the current
situation (few production systems with low load but coming soon more
productions with mich higher load)

On load tests I noticed after few minutes lots of crashed and then no
more database connections.

An exception like:

---- runtime exception report
--------------------------------------------------

Geronimo is the configured transaction manager but there was an error
getting a database Connection through Geronimo for the localpostgres
datasource. Please check your configuration, class path, etc.

Exception: java.lang.RuntimeException

Message: No ManagedConnections Available!

---- stack trace
---------------------------------------------------------------

java.lang.RuntimeException: No ManagedConnections Available!

org.ofbiz.minerva.pool.ObjectPool.getObject(ObjectPool.java:655)

org.ofbiz.minerva.pool.jdbc.xa.XAPoolDataSource.getConnection(XAPoolDataSource.java:355)

org.ofbiz.entity.transaction.MinervaConnectionFactory.getConnection(MinervaConnectionFactory.java:46)

org.ofbiz.geronimo.GeronimoTransactionFactory.getConnection(GeronimoTransactionFactory.java:94)

org.ofbiz.entity.transaction.TransactionFactory.getConnection(TransactionFactory.java:95)

org.ofbiz.entity.jdbc.ConnectionFactory.getConnection(ConnectionFactory.java:72)

org.ofbiz.entity.jdbc.SQLProcessor.getConnection(SQLProcessor.java:259)

org.ofbiz.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:365)

org.ofbiz.entity.datasource.GenericDAO.selectListIteratorByCondition(GenericDAO.java:737)

org.ofbiz.entity.datasource.GenericHelperDAO.findListIteratorByCondition(GenericHelperDAO.java:143)

org.ofbiz.entity.GenericDelegator.findListIteratorByCondition(GenericDelegator.java:1794)

org.ofbiz.entity.GenericDelegator.findByCondition(GenericDelegator.java:1694)

org.ofbiz.entity.GenericDelegator.findByCondition(GenericDelegator.java:1673)

org.ofbiz.entity.GenericDelegator.findByAnd(GenericDelegator.java:1567)

org.ofbiz.entity.GenericDelegator.findByAnd(GenericDelegator.java:1546)

sun.reflect.GeneratedMethodAccessor70.invoke(Unknown Source)

sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

java.lang.reflect.Method.invoke(Method.java:597)

bsh.Reflect.invokeOnMethod(Reflect.java:117)

bsh.Reflect.invokeObjectMethod(Reflect.java:91)

bsh.Name.invokeMethod(Name.java:689)

bsh.BSHMethodInvocation.eval(BSHMethodInvocation.java:55)

bsh.BSHPrimaryExpression.eval(BSHPrimaryExpression.java:69)

bsh.BSHVariableDeclarator.eval(BSHVariableDeclarator.java:85)

bsh.BSHTypedVariableDeclaration.eval(BSHTypedVariableDeclaration.java:64)

bsh.BSHBlock.eval(BSHBlock.java:79)

bsh.BSHBlock.eval(BSHBlock.java:44)

bsh.BSHIfStatement.eval(BSHIfStatement.java:48)

bsh.BSHBlock.eval(BSHBlock.java:79)

bsh.BSHBlock.eval(BSHBlock.java:44)

bsh.BSHTryStatement.eval(BSHTryStatement.java:86)

bsh.Interpreter.evalParsedScript(Interpreter.java:1104)




Then I have found that fix suggested at the end of this post:

http://n4.nabble.com/Do-we-need-to-manually-close-SQLProcesser-td164514.html#a164514

This indeed fixed the problem of losing connections..

But after I restarted the load tests, no the number of DB connections
keeps constant but the transactions become somehow blocked and I get this:

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)
/TransactionUtil.java:192                                                              



Best regards,
 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
>>>>    
>>>>        
>>>  
>>>      
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
In reply to this post by Scott Gray-2
The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc

So what I tried was to back port the transaction management - latest attempt is attached


thanks a lot,
 Florin
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
          
            
      
          
 
      

  


/*******************************************************************************
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 *******************************************************************************/
package org.ofbiz.entity.transaction;

import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Timestamp;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;
import javax.sql.XAConnection;
import javax.transaction.*;
import javax.transaction.xa.XAException;
import javax.transaction.xa.XAResource;

import org.apache.commons.collections.map.ListOrderedMap;
import org.ofbiz.base.util.Debug;
import org.ofbiz.base.util.UtilDateTime;
import org.ofbiz.base.util.UtilValidate;

/**
 * <p>Transaction Utility to help with some common transaction tasks
 * <p>Provides a wrapper around the transaction objects to allow for changes in underlying implementations in the future.
 */
public class TransactionUtil implements Status {
    // Debug module name
    public static final String module = TransactionUtil.class.getName();
    public static Map debugResMap = new HashMap();
    public static boolean debugResources = true;

    /** Begins a transaction in the current thread IF transactions are available; only
     * tries if the current transaction status is ACTIVE, if not active it returns false.
     * If and on only if it begins a transaction it will return true. In other words, if
     * a transaction is already in place it will return false and do nothing.
     */
    public static boolean begin() throws GenericTransactionException {
        return begin(0);
    }

    /** Begins a transaction in the current thread IF transactions are available; only
     * tries if the current transaction status is ACTIVE, if not active it returns false.
     * If and on only if it begins a transaction it will return true. In other words, if
     * a transaction is already in place it will return false and do nothing.
     */
    public static synchronized boolean begin(int timeout) throws GenericTransactionException {
        UserTransaction ut = TransactionFactory.getUserTransaction();
        if (ut != null) {
            try {
                int currentStatus = ut.getStatus();
                Debug.logVerbose("[TransactionUtil.begin] current status : " + getTransactionStateString(currentStatus), module);
                if (currentStatus == Status.STATUS_ACTIVE) {
                    Debug.logVerbose("[TransactionUtil.begin] active transaction in place, so no transaction begun", module);
                    return false;
                } else if (currentStatus == Status.STATUS_MARKED_ROLLBACK) {
                    Exception e = getTransactionBeginStack();
                    if (e != null) {
                        Debug.logWarning(e, "[TransactionUtil.begin] active transaction marked for rollback in place, so no transaction begun; this stack trace shows when the exception began: ", module);
                    } else {
                        Debug.logWarning("[TransactionUtil.begin] active transaction marked for rollback in place, so no transaction begun", module);
                    }

                    RollbackOnlyCause roc = getSetRollbackOnlyCause();
                    // do we have a cause? if so, throw special exception
                    if (roc != null && !roc.isEmpty()) {
                        throw new GenericTransactionException("The current transaction is marked for rollback, not beginning a new transaction and aborting current operation; the rollbackOnly was caused by: " + roc.getCauseMessage(), roc.getCauseThrowable());
                    } else {
                        return false;
                    }
                }

                // set the timeout for THIS transaction
                if (timeout > 0) {
                    ut.setTransactionTimeout(timeout);
                    Debug.logVerbose("[TransactionUtil.begin] set transaction timeout to : " + timeout + " seconds", module);
                }

                // begin the transaction
                ut.begin();
                Debug.logVerbose("[TransactionUtil.begin] transaction begun", module);

                // reset the timeout to the default
                if (timeout > 0) {
                    ut.setTransactionTimeout(0);
                }

                // reset the transaction stamps, just in case...
                clearTransactionStamps();
                // initialize the start stamp
                getTransactionStartStamp();
                // set the tx begin stack placeholder
                setTransactionBeginStack();

                // initialize the debug resource
                if (debugResources) {
                    DebugXaResource dxa = new DebugXaResource();
                    try {
                        dxa.enlist();
                    } catch (XAException e) {
                        Debug.logError(e, module);
                    }
                }

                return true;
            } catch (NotSupportedException e) {
                //This is Java 1.4 only, but useful for certain debuggins: Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("Not Supported error, could not begin transaction (probably a nesting problem)", e);
            } catch (SystemException e) {
                //This is Java 1.4 only, but useful for certain debuggins: Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("System error, could not begin transaction", e);
            }
        } else {
            Debug.logInfo("[TransactionUtil.begin] no user transaction, so no transaction begun", module);
            return false;
        }
    }

    /** Gets the status of the transaction in the current thread IF
     * transactions are available, otherwise returns STATUS_NO_TRANSACTION */
    public static int getStatus() throws GenericTransactionException {
        UserTransaction ut = TransactionFactory.getUserTransaction();
        if (ut != null) {
            try {
                return ut.getStatus();
            } catch (SystemException e) {
                throw new GenericTransactionException("System error, could not get status", e);
            }
        } else {
            return STATUS_NO_TRANSACTION;
        }
    }

    public static boolean isTransactionInPlace() throws GenericTransactionException {
        int status = getStatus();
        if (status == STATUS_NO_TRANSACTION) {
            return false;
        } else {
            return true;
        }
    }


    /** Commits the transaction in the current thread IF transactions are available
     *  AND if beganTransaction is true
     */
    public static void commit(boolean beganTransaction) throws GenericTransactionException {
        if (beganTransaction) {
            TransactionUtil.commit();
        }
    }

    /** Commits the transaction in the current thread IF transactions are available */
    public static void commit() throws GenericTransactionException {
        UserTransaction ut = TransactionFactory.getUserTransaction();

        if (ut != null) {
            try {
                int status = ut.getStatus();
                Debug.logVerbose("[TransactionUtil.commit] current status : " + getTransactionStateString(status), module);

                if (status != STATUS_NO_TRANSACTION) {
                    ut.commit();

                    // clear out the stamps to keep it clean
                    clearTransactionStamps();
                    // clear out the stack too
                    clearTransactionBeginStack();
                    clearSetRollbackOnlyCause();

                    Debug.logVerbose("[TransactionUtil.commit] transaction committed", module);
                } else {
                    Debug.logWarning("[TransactionUtil.commit] Not committing transaction, status is STATUS_NO_TRANSACTION", module);
                }
            } catch (RollbackException e) {
                RollbackOnlyCause rollbackOnlyCause = getSetRollbackOnlyCause();

                if (rollbackOnlyCause != null) {
                    // the transaction is now definitely over, so clear stuff as normal now that we have the info from it that we want
                    clearTransactionStamps();
                    clearTransactionBeginStack();
                    clearSetRollbackOnlyCause();
                   
                    Debug.logError(e, "Rollback Only was set when trying to commit transaction here; throwing rollbackOnly cause exception", module);
                    throw new GenericTransactionException("Roll back error, could not commit transaction, was rolled back instead because of: " + rollbackOnlyCause.getCauseMessage(), rollbackOnlyCause.getCauseThrowable());
                } else {
                    Throwable t = e.getCause() == null ? e : e.getCause();
                    throw new GenericTransactionException("Roll back error (with no rollbackOnly cause found), could not commit transaction, was rolled back instead: " + t.toString(), t);
                }
            } catch (IllegalStateException e) {
            /*Modification made by Virgil Botea in order to rollback the transactions that have failed to commit due an IllegalStateExacption*/
            rollback(true, "Could not commit transaction, IllegalStateException exception, rolling back", e);
            //Throwable t = e.getCause() == null ? e : e.getCause();
            //throw new GenericTransactionException("Could not commit transaction, IllegalStateException exception: " + t.toString(), t);
            } catch (HeuristicMixedException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("Could not commit transaction, HeuristicMixed exception: " + t.toString(), t);
            } catch (HeuristicRollbackException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("Could not commit transaction, HeuristicRollback exception: " + t.toString(), t);
            } catch (SystemException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("System error, could not commit transaction: " + t.toString(), t);
            }
        } else {
            Debug.logInfo("[TransactionUtil.commit] UserTransaction is null, not commiting", module);
        }
    }

    /** @deprecated */
    public static void rollback(boolean beganTransaction) throws GenericTransactionException {
        Debug.logWarning("WARNING: called rollback without debug/error info; it is recommended to always pass this to make otherwise tricky bugs much easier to track down.", module);
        rollback(beganTransaction, null, null);
    }
   
    /** Rolls back transaction in the current thread IF transactions are available
     *  AND if beganTransaction is true; if beganTransaction is not true,
     *  setRollbackOnly is called to insure that the transaction will be rolled back
     */
    public static void rollback(boolean beganTransaction, String causeMessage, Throwable causeThrowable) throws GenericTransactionException {
        if (beganTransaction) {
            TransactionUtil.rollback();
        } else {
            TransactionUtil.setRollbackOnly(causeMessage, causeThrowable);
        }
    }

    /** Rolls back transaction in the current thread IF transactions are available */
    public static void rollback() throws GenericTransactionException {
        UserTransaction ut = TransactionFactory.getUserTransaction();

        if (ut != null) {
            try {
                int status = ut.getStatus();
                Debug.logVerbose("[TransactionUtil.rollback] current status : " + getTransactionStateString(status), module);

                if (status != STATUS_NO_TRANSACTION) {
                    //if (Debug.infoOn()) Thread.dumpStack();
                    if (Debug.infoOn()) {
                        Exception newE = new Exception("Stack Trace");
                        Debug.logError(newE, "[TransactionUtil.rollback]", module);
                    }

                    // clear out the stamps to keep it clean
                    clearTransactionStamps();
                    // clear out the stack too
                    clearTransactionBeginStack();
                    clearSetRollbackOnlyCause();

                    ut.rollback();
                    Debug.logInfo("[TransactionUtil.rollback] transaction rolled back", module);
                } else {
                    Debug.logWarning("[TransactionUtil.rollback] transaction not rolled back, status is STATUS_NO_TRANSACTION", module);
                }
            } catch (IllegalStateException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("Could not rollback transaction, IllegalStateException exception: " + t.toString(), t);
            } catch (SystemException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("System error, could not rollback transaction: " + t.toString(), t);
            }
        } else {
            Debug.logInfo("[TransactionUtil.rollback] No UserTransaction, transaction not rolled back", module);
        }
    }

    /** Makes a rollback the only possible outcome of the transaction in the current thread IF transactions are available */
    public static void setRollbackOnly(String causeMessage, Throwable causeThrowable) throws GenericTransactionException {
        UserTransaction ut = TransactionFactory.getUserTransaction();
        if (ut != null) {
            try {
                int status = ut.getStatus();
                Debug.logVerbose("[TransactionUtil.setRollbackOnly] current code : " + getTransactionStateString(status), module);

                if (status != STATUS_NO_TRANSACTION) {
                    if (status != STATUS_MARKED_ROLLBACK) {
                        if (Debug.warningOn()) Debug.logWarning(new Exception(causeMessage), "[TransactionUtil.setRollbackOnly] Calling transaction setRollbackOnly; this stack trace shows where this is happening:", module);
                        ut.setRollbackOnly();
                        setSetRollbackOnlyCause(causeMessage, causeThrowable);
                    } else {
                        Debug.logInfo("[TransactionUtil.setRollbackOnly] transaction rollback only not set, rollback only is already set.", module);
                    }
                } else {
                    Debug.logWarning("[TransactionUtil.setRollbackOnly] transaction rollback only not set, status is STATUS_NO_TRANSACTION", module);
                }            
            } catch (IllegalStateException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("Could not set rollback only on transaction, IllegalStateException exception: " + t.toString(), t);
            } catch (SystemException e) {
                Throwable t = e.getCause() == null ? e : e.getCause();
                throw new GenericTransactionException("System error, could not set rollback only on transaction: " + t.toString(), t);
            }
        } else {
            Debug.logInfo("[TransactionUtil.setRollbackOnly] No UserTransaction, transaction rollback only not set", module);
        }
    }

    public static Transaction suspend() throws GenericTransactionException {
        try {
            if (TransactionUtil.getStatus() == TransactionUtil.STATUS_ACTIVE) {
                TransactionManager txMgr = TransactionFactory.getTransactionManager();
                if (txMgr != null) {
                    pushTransactionBeginStackSave(clearTransactionBeginStack());
                    pushSetRollbackOnlyCauseSave(clearSetRollbackOnlyCause());
                    Transaction trans = txMgr.suspend();
                    pushSuspendedTransaction(trans);
                    return trans;
                } else {
                    return null;
                }
            } else {
                Debug.logWarning("No transaction active, so not suspending.", module);
                return null;
            }
        } catch (SystemException e) {
            throw new GenericTransactionException("System error, could not suspend transaction", e);
        }
    }

    public static void resume(Transaction parentTx) throws GenericTransactionException {
        if (parentTx == null) return;
        try {
            TransactionManager txMgr = TransactionFactory.getTransactionManager();
            if (txMgr != null ) {
                setTransactionBeginStack(popTransactionBeginStackSave());
                setSetRollbackOnlyCause(popSetRollbackOnlyCauseSave());
                txMgr.resume(parentTx);
                removeSuspendedTransaction(parentTx);
            }
        } catch (InvalidTransactionException e) {
            /* NOTE: uncomment this for Weblogic Application Server
            // this is a work-around for non-standard Weblogic functionality; for more information see: http://www.onjava.com/pub/a/onjava/2005/07/20/transactions.html?page=3
            if (parentTx instanceof weblogic.transaction.ClientTransactionManager) {
                // WebLogic 8 and above
                ((weblogic.transaction.ClientTransactionManager) parentTx).forceResume(transaction);
            } else if (parentTx instanceof weblogic.transaction.TransactionManager) {
                // WebLogic 7
                ((weblogic.transaction.TransactionManager) parentTx).forceResume(transaction);
            } else {
                throw new GenericTransactionException("System error, could not resume transaction", e);
            }
            */
            throw new GenericTransactionException("System error, could not resume transaction", e);
        } catch (SystemException e) {
            throw new GenericTransactionException("System error, could not resume transaction", e);
        }
    }

    /** Sets the timeout of the transaction in the current thread IF transactions are available */
    public static void setTransactionTimeout(int seconds) throws GenericTransactionException {
        UserTransaction ut = TransactionFactory.getUserTransaction();
        if (ut != null) {
            try {
                ut.setTransactionTimeout(seconds);
            } catch (SystemException e) {
                throw new GenericTransactionException("System error, could not set transaction timeout", e);
            }
        }
    }

    /** Enlists the given XAConnection and if a transaction is active in the current thread, returns a plain JDBC Connection */
    public static Connection enlistConnection(XAConnection xacon) throws GenericTransactionException {
        if (xacon == null) {
            return null;
        }
        try {
            XAResource resource = xacon.getXAResource();
            TransactionUtil.enlistResource(resource);
            return xacon.getConnection();
        } catch (SQLException e) {
            throw new GenericTransactionException("SQL error, could not enlist connection in transaction even though transactions are available", e);
        }
    }

    public static void enlistResource(XAResource resource) throws GenericTransactionException {
        if (resource == null) {
            return;
        }

        try {
            TransactionManager tm = TransactionFactory.getTransactionManager();
            if (tm != null && tm.getStatus() == STATUS_ACTIVE) {
                Transaction tx = tm.getTransaction();
                if (tx != null) {
                     tx.enlistResource(resource);
                }
            }
        } catch (RollbackException e) {
            //This is Java 1.4 only, but useful for certain debuggins: Throwable t = e.getCause() == null ? e : e.getCause();
            throw new GenericTransactionException("Roll Back error, could not enlist resource in transaction even though transactions are available, current transaction rolled back", e);
        } catch (SystemException e) {
            //This is Java 1.4 only, but useful for certain debuggins: Throwable t = e.getCause() == null ? e : e.getCause();
            throw new GenericTransactionException("System error, could not enlist resource in transaction even though transactions are available", e);
        }
    }

    public static String getTransactionStateString(int state) {
        switch (state) {
            case Status.STATUS_ACTIVE:
                return "Transaction Active (" + state + ")";
            case Status.STATUS_COMMITTED:
                return "Transaction Committed (" + state + ")";
            case Status.STATUS_COMMITTING:
                return "Transaction Committing (" + state + ")";
            case Status.STATUS_MARKED_ROLLBACK:
                return "Transaction Marked Rollback (" + state + ")";
            case Status.STATUS_NO_TRANSACTION:
                return "No Transaction (" + state + ")";
            case Status.STATUS_PREPARED:
                return "Transaction Prepared (" + state + ")";
            case Status.STATUS_PREPARING:
                return "Transaction Preparing (" + state + ")";
            case Status.STATUS_ROLLEDBACK:
                return "Transaction Rolledback (" + state + ")";
            case Status.STATUS_ROLLING_BACK:
                return "Transaction Rolling Back (" + state + ")";
            case Status.STATUS_UNKNOWN:
                return "Transaction Status Unknown (" + state + ")";
            default:
                return "Not a valid state code (" + state + ")";
        }
    }

    public static void logRunningTx() {
        if (debugResources) {
            if (debugResMap != null && debugResMap.size() > 0) {
                Iterator i = debugResMap.keySet().iterator();
                while (i.hasNext()) {
                    Object o = i.next();
                    DebugXaResource dxa = (DebugXaResource) debugResMap.get(o);
                    dxa.log();
                }
            }
        }
    }

    public static void registerSynchronization(Synchronization sync) throws GenericTransactionException {
        if (sync == null) {
            return;
        }

        try {
            TransactionManager tm = TransactionFactory.getTransactionManager();
            if (tm != null && tm.getStatus() == STATUS_ACTIVE) {
                Transaction tx = tm.getTransaction();
                if (tx != null) {
                    tx.registerSynchronization(sync);
                }
            }
        } catch (RollbackException e) {
            //This is Java 1.4 only, but useful for certain debuggins: Throwable t = e.getCause() == null ? e : e.getCause();
            throw new GenericTransactionException("Roll Back error, could not register synchronization in transaction even though transactions are available, current transaction rolled back", e);
        } catch (SystemException e) {
            //This is Java 1.4 only, but useful for certain debuggins: Throwable t = e.getCause() == null ? e : e.getCause();
            throw new GenericTransactionException("System error, could not register synchronization in transaction even though transactions are available", e);
        }
    }

    // =======================================
    // =======================================
    private static ThreadLocal suspendedTxStack = new ThreadLocal();

    /** BE VERY CARFUL WHERE YOU CALL THIS!! */
    public static int cleanSuspendedTransactions() throws GenericTransactionException {
        Transaction trans = null;
        int num = 0;
        while ((trans = popSuspendedTransaction()) != null) {
            resume(trans);
            rollback();
            num++;
        }
        // no transaction stamps to remember anymore ;-)
        clearTransactionStartStampStack();
        return num;
    }
    public static boolean suspendedTransactionsHeld() {
        List tl = (List) suspendedTxStack.get();
        if (tl != null && tl.size() > 0) {
            return true;
        } else {
            return false;
        }
    }
    protected static void pushSuspendedTransaction(Transaction t) {
        List tl = (List) suspendedTxStack.get();
        if (tl == null) {
            tl = new LinkedList();
            suspendedTxStack.set(tl);
        }
        tl.add(0, t);
        // save the current transaction start stamp
        pushTransactionStartStamp(t);
    }
    protected static Transaction popSuspendedTransaction() {
        List tl = (List) suspendedTxStack.get();
        if (tl != null && tl.size() > 0) {
            // restore the transaction start stamp
            popTransactionStartStamp();
            return (Transaction) tl.remove(0);
        } else {
            return null;
        }
    }
    protected static void removeSuspendedTransaction(Transaction t) {
        List tl = (List) suspendedTxStack.get();
        if (tl != null && tl.size() > 0) {
            tl.remove(t);
            popTransactionStartStamp(t);
        }
    }

    // =======================================
    // =======================================
    private static ThreadLocal transactionBeginStack = new ThreadLocal();
    private static ThreadLocal transactionBeginStackSave = new ThreadLocal();

    private static void pushTransactionBeginStackSave(Exception e) {
        List el = (List) transactionBeginStackSave.get();
        if (el == null) {
            el = new LinkedList();
            transactionBeginStackSave.set(el);
        }
        el.add(0, e);
    }
    private static Exception popTransactionBeginStackSave() {
        List el = (List) transactionBeginStackSave.get();
        if (el != null && el.size() > 0) {
            return (Exception) el.remove(0);
        } else {
            return null;
        }
    }

    private static void setTransactionBeginStack() {
        Exception e = new Exception("Tx Stack Placeholder");
        setTransactionBeginStack(e);
    }
    private static void setTransactionBeginStack(Exception newExc) {
        if (transactionBeginStack.get() != null) {
            Exception e = (Exception) transactionBeginStack.get();
            Debug.logWarning(e, "WARNING: In setTransactionBeginStack a stack placeholder was already in place, here is where the transaction began: ", module);
            Exception e2 = new Exception("Current Stack Trace");
            Debug.logWarning(e2, "WARNING: In setTransactionBeginStack a stack placeholder was already in place, here is the current location: ", module);
        }
        transactionBeginStack.set(newExc);
    }
    private static Exception clearTransactionBeginStack() {
        Exception e = (Exception) transactionBeginStack.get();
        if (e == null) {
            Exception e2 = new Exception("Current Stack Trace");
            Debug.logWarning(e2, "WARNING: In clearTransactionBeginStack no stack placeholder was in place, here is the current location: ", module);
            return null;
        } else {
            transactionBeginStack.set(null);
            return e;
        }
    }
    public static Exception getTransactionBeginStack() {
        Exception e = (Exception) transactionBeginStack.get();
        if (e == null) {
            Exception e2 = new Exception("Current Stack Trace");
            Debug.logWarning(e2, "WARNING: In getTransactionBeginStack no stack placeholder was in place, here is the current location: ", module);
        }
        return e;
    }

    // =======================================
    // =======================================
    private static class RollbackOnlyCause {
        protected String causeMessage;
        protected Throwable causeThrowable;
        public RollbackOnlyCause(String causeMessage, Throwable causeThrowable) {
            this.causeMessage = causeMessage;
            this.causeThrowable = causeThrowable;
        }
        public String getCauseMessage() { return this.causeMessage + (this.causeThrowable == null ? "" : this.causeThrowable.toString()); }
        public Throwable getCauseThrowable() { return this.causeThrowable; }
        public void logError(String message) { Debug.logError(this.getCauseThrowable(), (message == null ? "" : message) + this.getCauseMessage(), module); }
        public boolean isEmpty() { return (UtilValidate.isEmpty(this.getCauseMessage()) && this.getCauseThrowable() == null); }
    }
   
    private static ThreadLocal setRollbackOnlyCause = new ThreadLocal();
    private static ThreadLocal setRollbackOnlyCauseSave = new ThreadLocal();

    private static void pushSetRollbackOnlyCauseSave(RollbackOnlyCause e) {
        List el = (List) setRollbackOnlyCauseSave.get();
        if (el == null) {
            el = new LinkedList();
            setRollbackOnlyCauseSave.set(el);
        }
        el.add(0, e);
    }
    private static RollbackOnlyCause popSetRollbackOnlyCauseSave() {
        List el = (List) setRollbackOnlyCauseSave.get();
        if (el != null && el.size() > 0) {
            return (RollbackOnlyCause) el.remove(0);
        } else {
            return null;
        }
    }

    private static void setSetRollbackOnlyCause(String causeMessage, Throwable causeThrowable) {
        RollbackOnlyCause roc = new RollbackOnlyCause(causeMessage, causeThrowable);
        setSetRollbackOnlyCause(roc);
    }
    private static void setSetRollbackOnlyCause(RollbackOnlyCause newRoc) {
        if (setRollbackOnlyCause.get() != null) {
            RollbackOnlyCause roc = (RollbackOnlyCause) setRollbackOnlyCause.get();
            roc.logError("WARNING: In setSetRollbackOnlyCause a stack placeholder was already in place, here is the original rollbackOnly cause: ");
            Exception e2 = new Exception("Current Stack Trace");
            Debug.logWarning(e2, "WARNING: In setSetRollbackOnlyCause a stack placeholder was already in place, here is the current location: ", module);
        }
        setRollbackOnlyCause.set(newRoc);
    }
    private static RollbackOnlyCause clearSetRollbackOnlyCause() {
        RollbackOnlyCause roc = (RollbackOnlyCause) setRollbackOnlyCause.get();
        if (roc == null) {
            /* this is an obnoxious message, leaving out for now; could be added manually if a problem with this is suspected
            if (Debug.verboseOn()) {
                // for this in particular, unlike the begin location, normally there will not be a setRollbackOnlyCause, so don't complain about it except in verbose
                Debug.logVerbose(new Exception("Current Stack Trace"), "In clearSetRollbackOnlyCause no stack placeholder was in place, here is the current location: ", module);
            }
            */
            return null;
        } else {
            setRollbackOnlyCause.set(null);
            return roc;
        }
    }
    public static RollbackOnlyCause getSetRollbackOnlyCause() {
        if (setRollbackOnlyCause.get() == null) {
            Exception e = new Exception("Current Stack Trace");
            Debug.logWarning(e, "WARNING: In getSetRollbackOnlyCause no stack placeholder was in place, here is the current location: ", module);
        }
        return (RollbackOnlyCause) setRollbackOnlyCause.get();
    }

    // =======================================
    // =======================================
   
    /**
     * Maintain the suspended transactions together with their timestamps
     */
    private static ThreadLocal suspendedTxStartStamps = new ThreadLocal() {
        public Object initialValue() {
            return new ListOrderedMap();
        }
    };
   
    /**
    * Put the stamp to remember later
    * @param t transaction just suspended
    */
    private static void pushTransactionStartStamp(Transaction t) {
        Map map = (Map) suspendedTxStartStamps.get();
        Timestamp stamp = (Timestamp) transactionStartStamp.get();
        if (stamp != null) {
            map.put(t, stamp);
        } else {
            Debug.logError("Error in transaction handling - no start stamp to push.", module);
        }
    }


    /**
    * Method called when the suspended stack gets cleaned by {@link #cleanSuspendedTransactions()}.
    */
    private static void clearTransactionStartStampStack() {
        ((Map) suspendedTxStartStamps.get()).clear();
    }

    /**
    * Remove the stamp of the specified transaction from stack (when resuming)
    * and set it as current start stamp.
    * @param t transaction just resumed
    */
    private static void popTransactionStartStamp(Transaction t) {
        Map map = (Map) suspendedTxStartStamps.get();
        if (map.size() > 0) {
            Timestamp stamp = (Timestamp) map.remove(t);
            if (stamp != null) {
                transactionStartStamp.set(stamp);
            } else {
                Debug.logError("Error in transaction handling - no saved start stamp found - using NOW.", module);
                transactionStartStamp.set(UtilDateTime.nowTimestamp());
            }
        }
    }

    /**
    * Remove the stamp from stack (when resuming)
    */
    private static void popTransactionStartStamp() {
        ListOrderedMap map = (ListOrderedMap) suspendedTxStartStamps.get();
        if (map.size() > 0) {
            transactionStartStamp.set(map.remove(map.lastKey()));
        } else {
            Debug.logError("Error in transaction handling - no saved start stamp found - using NOW.", module);
            transactionStartStamp.set(UtilDateTime.nowTimestamp());
        }
    }

    private static ThreadLocal transactionStartStamp = new ThreadLocal();
    private static ThreadLocal transactionLastNowStamp = new ThreadLocal();

    public static Timestamp getTransactionStartStamp() {
        Timestamp curStamp = (Timestamp) transactionStartStamp.get();
        if (curStamp == null) {
            curStamp = UtilDateTime.nowTimestamp();
            transactionStartStamp.set(curStamp);

            // we know this is the first time set for this transaction, so make sure the StampClearSync is registered
            try {
                registerSynchronization(new StampClearSync());
            } catch (GenericTransactionException e) {
                Debug.logError(e, "Error registering StampClearSync synchronization, stamps will still be reset if begin/commit/rollback are call through TransactionUtil, but not if otherwise", module);
            }
        }
        return curStamp;
    }

    public static Timestamp getTransactionUniqueNowStamp() {
        Timestamp lastNowStamp = (Timestamp) transactionLastNowStamp.get();
        Timestamp nowTimestamp = UtilDateTime.nowTimestamp();

        // check for an overlap with the lastNowStamp, or if the lastNowStamp is in the future because of incrementing to make each stamp unique
        if (lastNowStamp != null && (lastNowStamp.equals(nowTimestamp) || lastNowStamp.after(nowTimestamp))) {
            nowTimestamp = new Timestamp(lastNowStamp.getTime() + 1);
        }

        transactionLastNowStamp.set(nowTimestamp);
        return nowTimestamp;
    }

    protected static void clearTransactionStamps() {
        transactionStartStamp.set(null);
        transactionLastNowStamp.set(null);
    }

    public static class StampClearSync implements Synchronization {
        public void afterCompletion(int status) {
            TransactionUtil.clearTransactionStamps();
        }

        public void beforeCompletion() {
        }
    }
}
Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Scott Gray-2
I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 27/01/2010, at 1:53 PM, Florin Popa wrote:

> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>
> So what I tried was to back port the transaction management - latest attempt is attached


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
I was just asking myself if someone encountered before such problems on
older revisions..

Would be Geronimo ok to be used or shall I try something else?

regards,
 Florin

> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>
>  
>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>
>> So what I tried was to back port the transaction management - latest attempt is attached
>>    
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Jacques Le Roux
Administrator
I upgraded 2 systems from Minerva (R4.0) to DBCP for clients of mine but I don't know if it's the kind of problems you encounter. It
seems that you are facing more. Not sure as I have, like you, not much time to look at it

Jacques

From: "Florin Popa" <[hidden email]>

>I was just asking myself if someone encountered before such problems on
> older revisions..
>
> Would be Geronimo ok to be used or shall I try something else?
>
> regards,
> Florin
>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>>
>>
>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I
>>> am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>>
>>> So what I tried was to back port the transaction management - latest attempt is attached
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

David E. Jones-2
In reply to this post by Florin Popa

You're using a quite old version of OFBiz with the Minerva connection pool (I can tell from the stack trace you sent earlier). The Minerva connection pool has some issues with resetting connections when there are errors, especially if there is any code that doesn't manage errors well, but also if there are network layer issues or other sorts of things... it just doesn't recover at all.

You could try making changes to use the Apache DBCP connection pool that we use now in OFBiz. To do so requires some low-level coding. You can look at the current code base for hints, but there is still some work.

There are no known workarounds to this issue for really high volume sites, and for low-medium volume sites the workaround was to restart the app server(s) every day.

-David


On Jan 27, 2010, at 3:01 PM, Florin Popa wrote:

> I was just asking myself if someone encountered before such problems on older revisions..
>
> Would be Geronimo ok to be used or shall I try something else?
>
> regards,
> Florin
>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>>
>>  
>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>>
>>> So what I tried was to back port the transaction management - latest attempt is attached    
>>
>>  
>

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Jacques Le Roux
Administrator
And even after that you would need to enhance the system with change done since that. Especially is you use a system with a load
balancer. But Minerva to DBCP is the big one, yes

Jacques

From: "David E Jones" <[hidden email]>

>
> You're using a quite old version of OFBiz with the Minerva connection pool (I can tell from the stack trace you sent earlier). The
> Minerva connection pool has some issues with resetting connections when there are errors, especially if there is any code that
> doesn't manage errors well, but also if there are network layer issues or other sorts of things... it just doesn't recover at all.
>
> You could try making changes to use the Apache DBCP connection pool that we use now in OFBiz. To do so requires some low-level
> coding. You can look at the current code base for hints, but there is still some work.
>
> There are no known workarounds to this issue for really high volume sites, and for low-medium volume sites the workaround was to
> restart the app server(s) every day.
>
> -David
>
>
> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote:
>
>> I was just asking myself if someone encountered before such problems on older revisions..
>>
>> Would be Geronimo ok to be used or shall I try something else?
>>
>> regards,
>> Florin
>>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>>>
>>>
>>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences...
>>>> I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>>>
>>>> So what I tried was to back port the transaction management - latest attempt is attached
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
In reply to this post by David E. Jones-2
Thanks everyone for the help!

Today we succeeded port to geronimo transaction 2.1 as well as the
switch from minerva to DBCP connection pool. It seems much better but I
am not fully content :)
Maybe because the automated testing tool I am using can not really hit
hard enough..

Any recommendation for such tools?


Of course upgrade to latest version was scheduled too but this would
take longer..

Best regards,
 Florin

> You're using a quite old version of OFBiz with the Minerva connection pool (I can tell from the stack trace you sent earlier). The Minerva connection pool has some issues with resetting connections when there are errors, especially if there is any code that doesn't manage errors well, but also if there are network layer issues or other sorts of things... it just doesn't recover at all.
>
> You could try making changes to use the Apache DBCP connection pool that we use now in OFBiz. To do so requires some low-level coding. You can look at the current code base for hints, but there is still some work.
>
> There are no known workarounds to this issue for really high volume sites, and for low-medium volume sites the workaround was to restart the app server(s) every day.
>
> -David
>
>
> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote:
>
>  
>> I was just asking myself if someone encountered before such problems on older revisions..
>>
>> Would be Geronimo ok to be used or shall I try something else?
>>
>> regards,
>> Florin
>>    
>>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>>>
>>>  
>>>      
>>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>>>
>>>> So what I tried was to back port the transaction management - latest attempt is attached    
>>>>        
>>>  
>>>      
>
>
>  

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

David E. Jones-2

The Grinder is a nice tool for such things (and has a nice recording proxy).

BTW, make sure to set your HTTP and thread pool sizes adequately for the load you are planning on.

-David


On Jan 28, 2010, at 11:30 AM, Florin Popa wrote:

> Thanks everyone for the help!
>
> Today we succeeded port to geronimo transaction 2.1 as well as the switch from minerva to DBCP connection pool. It seems much better but I am not fully content :)
> Maybe because the automated testing tool I am using can not really hit hard enough..
>
> Any recommendation for such tools?
>
>
> Of course upgrade to latest version was scheduled too but this would take longer..
>
> Best regards,
> Florin
>> You're using a quite old version of OFBiz with the Minerva connection pool (I can tell from the stack trace you sent earlier). The Minerva connection pool has some issues with resetting connections when there are errors, especially if there is any code that doesn't manage errors well, but also if there are network layer issues or other sorts of things... it just doesn't recover at all.
>>
>> You could try making changes to use the Apache DBCP connection pool that we use now in OFBiz. To do so requires some low-level coding. You can look at the current code base for hints, but there is still some work.
>>
>> There are no known workarounds to this issue for really high volume sites, and for low-medium volume sites the workaround was to restart the app server(s) every day.
>>
>> -David
>>
>>
>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote:
>>
>>  
>>> I was just asking myself if someone encountered before such problems on older revisions..
>>>
>>> Would be Geronimo ok to be used or shall I try something else?
>>>
>>> regards,
>>> Florin
>>>    
>>>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>>>>
>>>>      
>>>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>>>>
>>>>> So what I tried was to back port the transaction management - latest attempt is attached            
>>>>      
>>
>>
>>  
>

Reply | Threaded
Open this post in threaded view
|

Re: Any chance for an upgrade? - help please

Florin Popa
I'll take a look ar Grinder, seems promising, thanks again.

Of course life is never easy :) now I have another problem... the
network admin configured 2 ofbiz instances having an apache in front of
them as balancer.. but apache "talks" with ofbiz instances via AJP
rather than mod_jk ..which seems to be a bottleneck..
Have you experienced that kind of things?

best regards,
 Florin Popa


> The Grinder is a nice tool for such things (and has a nice recording proxy).
>
> BTW, make sure to set your HTTP and thread pool sizes adequately for the load you are planning on.
>
> -David
>
>
> On Jan 28, 2010, at 11:30 AM, Florin Popa wrote:
>
>  
>> Thanks everyone for the help!
>>
>> Today we succeeded port to geronimo transaction 2.1 as well as the switch from minerva to DBCP connection pool. It seems much better but I am not fully content :)
>> Maybe because the automated testing tool I am using can not really hit hard enough..
>>
>> Any recommendation for such tools?
>>
>>
>> Of course upgrade to latest version was scheduled too but this would take longer..
>>
>> Best regards,
>> Florin
>>    
>>> You're using a quite old version of OFBiz with the Minerva connection pool (I can tell from the stack trace you sent earlier). The Minerva connection pool has some issues with resetting connections when there are errors, especially if there is any code that doesn't manage errors well, but also if there are network layer issues or other sorts of things... it just doesn't recover at all.
>>>
>>> You could try making changes to use the Apache DBCP connection pool that we use now in OFBiz. To do so requires some low-level coding. You can look at the current code base for hints, but there is still some work.
>>>
>>> There are no known workarounds to this issue for really high volume sites, and for low-medium volume sites the workaround was to restart the app server(s) every day.
>>>
>>> -David
>>>
>>>
>>> On Jan 27, 2010, at 3:01 PM, Florin Popa wrote:
>>>
>>>  
>>>      
>>>> I was just asking myself if someone encountered before such problems on older revisions..
>>>>
>>>> Would be Geronimo ok to be used or shall I try something else?
>>>>
>>>> regards,
>>>> Florin
>>>>    
>>>>        
>>>>> I'm sorry the potential for problems with this approach is just too large for me to be able to help you through it.
>>>>>
>>>>> Regards
>>>>> Scott
>>>>>
>>>>> HotWax Media
>>>>> http://www.hotwaxmedia.com
>>>>>
>>>>> On 27/01/2010, at 1:53 PM, Florin Popa wrote:
>>>>>
>>>>>      
>>>>>          
>>>>>> The attempt to update Ofbiz to recent revision is for the moment (time limits) not possible.. there are so many differences... I am even not sure if bsh could work further instead of the newly groovy ?! ....also the entity layer handling.. etc
>>>>>>
>>>>>> So what I tried was to back port the transaction management - latest attempt is attached            
>>>>>>            
>>>>>      
>>>>>          
>>>  
>>>      
>
>
>  

12