Is there a way to make a service-call from a link transition that will honor the transaction-timeout parameter?

Technical Questions
1

So, we have the following service call (just showing the header):

    <service verb="update" noun="PaymentMethodFileStatus" transaction-timeout="6000" semaphore="fail" semaphore-parameter="paymentMethodFileId">
        <in-parameters>
            <parameter name="paymentMethodFileId" required="true"/>
            <parameter name="statusId" required="true"/>
            <parameter name="statusDate" default="ec.user.nowTimestamp"/>
        </in-parameters>

And a screen with this transition:

    <transition name="markPaymentMethodFileAsSent">
        <service-call name="sssonline.basalt.PaymentMethodServices.update#PaymentMethodFileStatus"
                      in-map="[paymentMethodFileId: paymentMethodFileId,
                               statusId:            'PmfsSent']"/>
        <default-response url="."/>
    </transition>

And in the screen, a field with a link:

                    <field name="paymentMethodFileId">
                        <default-field title="File ID">
                            <link url="paymentMethodFiles" text="${paymentMethodFileId}" link-type="anchor" condition="paymentMethodFileId"/>
                        </default-field>
                    </field>

I’ve tried adding the transaction-timeout to the service-call in the transition as well…it has no effect. Essentially after 60 seconds goes by, I’ll get a Bitronix timeout.

So…my alternative is to make a service job out of it…and have it run in the background. I know it’ll work and I know it’ll honor the the transaction timeout.

But we also have another like this…that returns a larger PDF which also suffers the same timeout issue. That one is more annoying as while we can do that as part of a service job, we would now need to store the resulting PDF instead of just producing it on the fly.

Anyway, I suspect “you shouldn’t want to do that” is probably the answer…but, it still doesn’t explain why the transaction timeout isn’t honored.

2

By default a transaction is started for a transition, unless you use the begin-transaction=“false” attribute (see ServiceRun.xml in the tools app for an example). That may be what you’re running into, but the transaction-timeout attribute on the transition element should have an effect.

On the other hand, are you sure it is a transaction timeout? It could also be an HTTP request timeout, which usually happens at 60 seconds (may be triggered by proxy, servlet container, or client). You can usually tell the difference from the logs, for example a broken pipe exception is a sign that the HTTP request timed out.

Sometimes a long running transition will work, but only as long as the initial HTTP response is within 60 seconds. And yes, like you mentioned, even if that works it’s not the best design! This is the reason the Data Snapshot screen uses a service job plus a local directory for the snapshot files, as those can take a while to run.

3

Thank you David, yes, I’ll just convert them to service jobs. The customer had 1200 employees come on and we just experienced new limits and I was trying to get by on check printing day.

It is long enough that a browser timeout seemed likely, I agree. The logs seemed to indicate there wasn’t a valid transaction (I got familiar errors to when a timeout occurs such as an error finding one on something that exists)…but either way, making it run longer isn’t really a good idea anyway. We must have been just on the cusp of the 60 seconds, as taking the server down and up, it was able to complete. We’ve got another 2-3000 employees coming though, so there really is no choice but to make it a service job (and profile it, which I’ll do as well to see if I can speed it up).

Anyway, thank you, David

1 Like
4

For those that don’t know…you can enable profiling by dropping this xml in the actions section (or wherever) and it’ll give you a wealth of information. I’ll still end up doing service jobs, but I was able to combine a couple of services hitting the same view entity and shave about 35% off the total time of the service call.

<script>ec.artifactExecution.logProfilingDetail()</script>
2 Likes