Call Flow FAQ

Yamini Kalyandurga
Consulting Member of Technical Staff
Couple of months back, I blogged about how to use call flow feature in SailFin. There has been a lot of discussion around this feature and so I came up with this FAQ that will answer some of the common queries on call flow.

Q. What is call flow?

People familiar with SIP would at first mistake it with SIP call flow (RFC 3665) which is nothing but the sequence of a SIP call. But what we are referring to here is the request call flow monitoring feature of GlassFish. SailFin extends the call flow functionality of GlassFish to trace SIP request times in the SIP container.

Q. How does call flow work?

An agent called the CallFlow agent serves as the input point where all the call flow data is collected. Containers like Web Container, EJB Container, SIP container etc. make a call to the CallFlow agent to push information into the CallFlow layer. Various trap points (probes) are inserted at appropriate places to collect request start/end, method start/end data. It also collects information like transaction id, user principal, method name, application name and all this information is persisted into a database. User can then view this data in the admin console (GUI)

Q. When exactly should one use call flow monitoring?

An application developer or server administrator can use this feature at development time to see how the application behaves in the server.

Q What is the correct procedure to use call flow?

Here are the steps:
1. First enable call flow using the CLI or GUI.
2. Start the requests. Instead of continuously loading the server, send limited requests (say 100 requests).
3. Wait for all the requests to complete.
4. View the data in GUI (by clicking on Refresh in the call flow monitoring screen)

Q Does the call flow enable setting persist over server restarts?

No, call flow can be enabled only on a running server instance. Hence, you would need to enable it each time server is started.

Q What will happen if I disable call flow when the server is still processing requests?

Partial data would be written for the request. For example, if you disable call flow when the request start time has been recorded, the request end data wouldn't be written to the database. So when GUI queries the data to display, some of the requests would be missed.

Q Why isn't call flow recommended for production use?

For every request that comes into the server, a set of records are created that are written to an embedded database (JavaDB). The more the number of requests, the more the number of records. There are 'n' number of threads that are being used to produce data and there is just a single (asynchronous) thread that writes to the DB. So, under load, there is a performance impact. Also the server creates a lot of transaction objects before writing to the database. This can lead to transient memory usage. The objects get cleaned up only after call flow is disabled.

Q I understand this feature is a development only feature and not recommended for production use. However, can I use it atleast under moderate loads?

Yes, you can if you tune the call flow agent. In case of SIP apps, we have tested this feature for call rate of 10 cps. Set the following JVM options. The following properties tune the request tables. The containertime.qsize table roughly fills up 2-3x faster than the other table.



The asynchronous thread that writes to the database sleeps for 5secs by default. You can decrease the time so that the queue writes faster to the database and the memory requirements don't shoot up.


Feel free to contact me if you have any queries related to call flow.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.