Hi

AES 6.3.3 Patch 8 ACM 6.3

How long would you expect for a call to registerTerminal to take?

I have a legacy java DMCC web app that fails every now and again (yes - production and No - not certified so I'm on my own here!)

The app logging shows most calls to registerTerminal return within a few tens of milli-seconds but the odd one (and I believe this either the issue or a root symptom) takes over 10 seconds (i.e. approx 1000 times longer). I can't tell if this call times out (user tries to refresh / register repeatedly and muddies the logs) but the AES session gets torn down. The log shows a call to unregisterTerminal has timed out which is a an artifact of the impatient user. I can patch the code to prevent multiple attempts (checking the state of the terminal prior to the attempt)

So is a 10s+ time for registerTerminal within the normal range of expectation (the call to registerTerminal is synchronous with all the pitfalls)

Thanks

I have seen terminal registration taking several seconds in my lab many times. I do not think that 10s is abnormally long.

It sounds like your application is making a synchronous call when registering the terminal. It would probably be better to use the asynchronous service.

You should also check that you are not using a thread belonging to the SDK when making an API call. For example, you must never make an API call in event listener code as the thread running this code belongs to the SDK and it needs it back to service other events. Using this thread to make API calls can lead to deadlock.

Martin

Thanks for the answer. The long time to return is usually seen at peak times so consistent with loads. I don't think we are breaching the Sea limits for registration in parallel but it's possible I suppose.

You are quite correct; the call to registerTerminal is synchronous. The whole application is fundamentally flawed and needs to be respected redesigned and rewritten....

At the moment I need to apply a sticking plaster solution for the issue of a user signing in on 1 thread (which takes long time to return) and then signing out on another thread before the 1st call returns.

Once I have that in place I can go back yo the drawing board.

Communication Manager has a number of layers of 'protection' built into it so that it does not turn into a quivering mass of jelly when it gets loaded up. We refer to this as hyperactivity or overload protection. These layers get triggered by overall system occupancy and traffic load (requests per unit time in a sliding window). When these thresholds are tripped, the system changes behavior for some period of time trying to shed "low priority" work. In a lab environment I would never expect to hit these thresholds, however in production it is certainly possible (in fact many of them were developed in reaction to situations encountered in a production environment). One of these overload protection mechanisms is a behavior to ignore registration requests (the station device will normally retry after some period). I presume you are encountering this form of overload protection. The strategy in the phones is to let the request time out, and have a back off strategy - first retry in N seconds, second retry in N+M seconds, third in N+M+O seconds, etc similar to a TCP retry strategy. The end user has little control over when these retries occur.

Thanks John.

Are there any log signatures that show if we are encountering a 'shields up' response from ACM and requiring us to back off?