cancel
Showing results for 
Search instead for 
Did you mean: 

Root Cause analysis JDBC Sender channel not processing the messages .

Former Member
0 Kudos

Hi Sdn Team,

We had an issue where our JDBC Sender channel was not processing the messages. In CC monitoring it is showing in

Green , In CC the Interface is polling for messages to DB server as per polling interval. But it is not processing the msg's. Under Processing detials for cluster node it is showing only "Processing Started" for each polling interval.

with the Help of this thread we could solve the issue (Thnaks a lot to SDN). As per the Thread we did the same and the issue was solved

Check in the Visual Admin >Cluster> "LOCKING ADAPTER"

we get a option of Display Locks .Check for an entry with

NAME : $XIDBAD.JDBC2XI

reset the locks and restart the CC ,now it works fine.

Note 1083488 - XI FTP/JDBC sender channel stop polling indefinitely(04/04S)

There is some thing intriguing with the issue there are four Interfaces which are running on JDBC , but only one Interface was not processing the messages after the remedial procedures suggested by sdn thread , we could solve the problem.

I would like to Know the root cause analys of the problem, and why only one Interface was not working and how the steps which has mentioned in the sdn Thread helped us.

Thanks.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Madhu,

In my opinion, this is not a problem with JDBC adapter as a whole but with specific interface (or thread of JDBC adapter). Root cause behind this issue is that particular thread/interface/communication channel is waiting for old task to complete (which might be in niether in error nor completed) hence created lock situation on particular table (imagine indefinite loop without any exit condition).

Because of this reason adapter keep polling (false polling) but not retrieving any data, since there is no error you won't see any red light in CC monitoring.

I am not sure if this problem can be recreated (may be if you set polling interval to close to 0 or some deliberate network hiccup during large DB read). There is new table parameter 'taskTimeout' to avoid this problem and ideally should be part of all JDBC CC. Set value taskTimeout = x where x >0 value (also mention in Note:1083488).

Since this problem is not related to entire JDBC adapter but only to particular instance of communication channel that's why all other JDBC interfaces are working.

I hope this answers your query.

Regards,

Gourav

Answers (2)

Answers (2)

Former Member
0 Kudos

task time out parmeter and change in the code of SQL

Former Member
0 Kudos

Any inputs Team,

Regards.