Hi, We have complete tempo based application and chaining breaks here

That's correct, that's a good place to monitor. Also review the db_PX*.log that correspond to the engine where your process where the chaining broke.

db_PX001*.log: EXEC00
db_PX011*.log: EXEC01
db_PX021*.log: EXEC02

You can determine in what engine a process is running by adding a column to the Processes report defined as

=process_ee_id()

a) This is what you will see if the number of nodes is exceeded (in the example my model is called "My model")

2014-06-24 05:38:32 [PX001] {pe40.kdb 759} (Default) WARN .a.p.PROCESS.i "[P25-My model with activity chaining] [Activity Chaining] Could not chain to attended activity. Limit of 50 unattended nodes executed was reached."

b) This is what you will see if the activity chaining breaks for other reason (such as time, a timer or non-chained paths)

2014-06-24 06:21:58 [PX021] {pe41.kdb 644} (Default) WARN .a.p.PROCESS.i "[Activity Chaining] Could not chain to attended activity. No attended activity with compatible assignment was found."

When troubleshooting issues like this focus on:

1. The suggestion posted above (use of db_PX*.log files)
2. Counting the nodes including those running MNI (multiple node instances)
3. Checking times
4. Looking for timer events (which will break the chain right away by default) or unchained paths that may get trigger sometimes only (explaining why the chain breaks only sometimes)

Thanks , this helps!

Eduardo, I looked into the node details for one of the process model where I thought broken chain was the issue and we fixed it. However, when I am trying to see the time taken for optimizing that more, it seems that the addition of all times between two screens is way more than 8 secs and still the chaining does not break. I feel that the time is not shown correctly sometimes or is there a configuration to check that out?

I mean , is there a setting to be done in custom.properties for the same.
Got this one though:
server.conf.exec.CHAINED_EXECUTION_NODE_LIMIT=
100