Hi Nicolas,
I have no objection but I don't think it is something I would ever use. I
would either fix the screen or increase the timeout for that specific
screen.
Regards
Scott
On Fri, 20 Sep 2019 at 20:20, Nicolas Malin <nicolas.ma...@nereide.fr>
wrote:
> Hello Scott, thanks for your return,
>
> in line ...
>
> On 9/17/19 10:45 AM, Scott Gray wrote:
> > Has anyone ever had a good experience with transaction timeouts? I feel
> > like they achieve nothing useful in that:
> > 1. They don't interrupt any work that is taking too long (they just
> prevent
> > it from being committed)
> > 2. By the time the exception is thrown, all the work is already done and
> > the result is that it just gets thrown away in exchange for an error
> >
> > Surely there's a positive side to them, and I've just never seen it?
>
> Completely agree, it's also my life :) , transaction timeout it's just a
> pain to be sure that you waste your time.
>
> Currently the advantage that I saw, it's detect an unexpected too long
> service and help to spend enough time to optimize it or thinking about
> an other solution.
>
> > But Nicolas, in your case I think the solution lies elsewhere. I don't
> > think it's ever ok for a screen to take over a minute to load and tie up
> > the http connection all that time. Slow pages happen to all of us, but
> IMO
> > the solution always lies in making the screen faster, limiting the amount
> > of data that can be processed in a single request or by making the
> request
> > asynchronous.
>
> Sure, I'll join you there. It's generally my first step, currently I
> most concentrate on the second step, decrease error raise where there is
> no benefit.
>
> Do you have an objection if I implement the properties explained below
> with the current default value (60s)? Like this no change for general
> case, and for server with high load, free will for administrator site to
> adjust it.
>
> Cheers,
>
> Nicolas
>
> >
> > Regards
> > Scott
> >
> > On Wed, 11 Sep 2019 at 06:57, Nicolas Malin <nicolas.ma...@nereide.fr>
> > wrote:
> >
> >> Hi all,
> >>
> >> Since I increase the sensibility of error message [1], we have on
> >> different screen that take some time to rendering an error throw due to
> >> transaction timeout.
> >>
> >> By default each screen is rendering with the default timeout (60s) that
> >> isn't enough when you have big data compilation or some external service
> >> latency.
> >>
> >> Of course it's possible to analyze each case with purpose to increase
> >> the screen velocity or set a transaction-timeout on screen definition,
> >> but as first easy step what do you think if we add a default transaction
> >> timeout for screen to 10 minutes with possibility to override by
> >> properties ?
> >>
> >> Example:
> >>
> >> *****************************
> >>
> >>
> >>
> framework/widget/src/main/java/org/apache/ofbiz/widget/model/ModelScreen.java
> >> @@ -122,7 +123,7 @@ public class ModelScreen extends ModelWidget {
> >> // wrap the whole screen rendering in a transaction, should
> >> improve performance in querying and such
> >> Map<String, String> parameters =
> >> UtilGenerics.cast(context.get("parameters"));
> >> boolean beganTransaction = false;
> >> - int transactionTimeout = -1;
> >> + int transactionTimeout =
> >> UtilProperties.getPropertyAsInteger("widget",
> >> "widget.transaction.timeout.default", 600);
> >> if (parameters != null) {
> >> String transactionTimeoutPar =
> >> parameters.get("TRANSACTION_TIMEOUT");
> >> if (transactionTimeoutPar != null) {
> >> @@ -152,12 +153,7 @@ public class ModelScreen extends ModelWidget {
> >> // If transaction timeout is present, use it to start the
> >> transaction
> >> // If transaction timeout is set to zero, no transaction
> >> is started
> >> if (useTransaction) {
> >> - if (transactionTimeout < 0) {
> >> - beganTransaction = TransactionUtil.begin();
> >> - }
> >> - if (transactionTimeout > 0) {
> >> - beganTransaction =
> >> TransactionUtil.begin(transactionTimeout);
> >> - }
> >> + beganTransaction =
> >> TransactionUtil.begin(transactionTimeout);
> >> }
> >>
> >> // render the screen, starting with the top-level section
> >>
> >> *******************************
> >>
> >> Any remarks ?
> >>
> >> In parallel i will investigate why the error message catch is so
> sensible.
> >>
> >> Nicolas
> >>
> >> [1] http://svn.apache.org/viewvc?view=revision&revision=1856175
> >>
> >> --
> >> logoNrd <https://nereide.fr/>
> >> Nicolas Malin
> >> The apache way <http://theapacheway.com/> : *Charity* Apache’s mission
> >> is providing software for the public good.
> >> informat...@nereide.fr
> >> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >>
> >> Apache OFBiz <http://ofbiz.apache.org/>|The Apache Way
> >> <http://theapacheway.com/>|réseau LE <http://www.libre-entreprise.org/>
> >>
>
