Clarity

I am facing an issue with Clarity processes on 13.3, recently upgraded. Any process in Clarity triggered taking about a min or two to start with actual work. That is there is a delay between process start time and start steps start time. Once its on Start step it goes through quickly.

I tried to resolve issue by

# restarting BGs, Beacons

# Remove , Add BGs

# increase bg memory to max 2G

No errors in any logs, there are no stuck old processes. Now I am clue less. Please suggest..!

Hi All - Any ideas here for Kumu? Thanks! Chris

Kumu C wrote:

 

I am facing an issue with Clarity processes on 13.3, recently upgraded. Any process in Clarity triggered taking about a min or two to start with actual work. That is there is a delay between process start time and start steps start time. Once its on Start step it goes through quickly.

 

I tried to resolve issue by

# restarting BGs, Beacons

# Remove , Add BGs

# increase bg memory to max 2G

 

No errors in any logs, there are no stuck old processes. Now I am clue less. Please suggest..!

Hi Kumu002,

Have you checked for multicast issues in the environment?

Please check Sean Harp's reply in the following thread - https://communities.ca.com/message/106469751#106469751

Thank you,

Ruchika

Thanks Ruchika, however its not multicast issues, in this case its set correctly and its only one server application. Case is with support and pending for long time.

Hi Kumu002,

Delay in process could be due to many facts, 1 of them is multicast. So few questions i have

1. How many number of completed/error process

2. Do you have the bind address filled in CSA?

3. Does your app server & database server is on the same time zone?

Regards

Suman Pramanik

Hi Suman,

- No error ed process, completed are about 30 processes from last 3 days.

- No bind address in CSA, its single server application.

- Yes, DB and app in the same timezone, in fact same server.

Hi Kumu002,

Can you please put the IP address of the application server in the bind address and see if it improves.

Regards

Suman Pramanik

Thanks Suman - did try the IP in bind address, however that didn't helped.

Hi Kumu002,

Can you please raise a case with support so that we can take a deeper look.

Regards

Suman Pramanik

Case is already open with support its been a while, provided logs and dumps for detail investigation. Thanks.

Have you checked for any orphan processes, or tried what Suman asked ?

NJ

I still not get exact reason for this issue, have seen this in different  systems. It appears to be related to BG some how because in some cases process and jobs both gets affected, they takes a min or 2 to actually start. Please let me know if any information on this.

There is no stuck or old processes, BG is healthy no errors in any logs related.

It is almost certainly to be a multicast communication/configuration issue.  Being a single server application does not exempt this, multicast is not merely about clustering but is a working requirement for every installation of Clarity no matter the environment setup.

The only other alternative that sometimes arises is when the NMS Message Receiver thread would 'die' due to some issue in the bg service, however that should be accompanied by an error in the bg logs, and even if it isn't, using a command like 'jstack -l <pid>' on the java.exe process running your bg service should reveal all the running threads and confirm if that one is still listed - something that Support could take you through on the issue if they suspected that as the cause.

However, given you seemed unaware of the importance of working multicast for your environment in order to be able to handle fired events without delay, I would still suspect that is going to be behind your reason for this happening.