How to Prevent Thread Hung

[Venkata_Kasi_Viswanath_Mugada1 (Kasi Mugada)]

Killing threads does not quality as a solution and I’m strongly against using a script or any “fix” to kill threads - it will just be a band-aid fix and cause a ton more problems across all domains.

Do get back to us after checking the points I mentioned above - I suspect locked and waiting threads.

KM

[Jerry_kurian]

@Venkata_Kasi_Viswanath_Mugada1

as a solution and I’m strongly against using a script or any “fix” to kill threads - it will just be a band-aid fix and cause a ton more problems across all domains.

Do get back to us after checking the points I

Is this same adapter connection being used for reading and writing to the same tables which the DBA’s have seen locks on?

[Tegar_ASK]

thankyou Kasi for your advice
we won’t do killing the thread,
we gonna setting up our jdbc as you mention above
I do have the same suspect as yours…

Best Regards

[Tegar_ASK]

@Jerry_kurian

Is this same adapter connection being used for reading and writing to the same tables which the DBA’s have seen locks on?

yup, the exact same username access and adapter sir

[Jerry_kurian]

Hi @Tegar_ASK ,
This might be a case of one adapter connection trying to auto-commit a record on a record or page while another connection is trying to read data from the same block.
You might have to think of the folloing approach

• Keep your existing services which perform insert’s, updates, deletes using the same adapter connection.
  -Create a new adapter connection to the same database only for read purposes with the settings of transaction isolation (provided it suits your requirements) such as being able to ready uncommitted data.

This is just a though -btw changing the reading adapter service which does the read is not as hard as it seems you could refer to pub.art.service:setAdapterServiceNodeConnection which can do this task without your team having to rebuild the code.

Regards
~jerry

[reamon]

There is a timeout on the adapter service itself. The adapter connection settings you list are for the connection session, not the execution of a statement. The fun part is when it is created it defaults to -1 which means “wait forever.” Should never do that on any adapter calls (DB or other) nor on any HTTP calls.

Not sure if that is the case here but is something to check.

[reamon]

Adding detail to the settings you shared:

Block timeout is the amount of time a thread will wait for a pool connection before giving up and throwing an error. This has nothing to do when an individual adapter service waits for a response. This applies only to threads waiting to get a connection from the pool.

Expire timeout is the amount of time a connection in the pool is allowed to remain idle. If not used within the expire timeout, the connection will be closed (should be set to just short of what the DB idle connection timeout is).