We are using AppDynamics to instrument a client-server application (Java Swing client, C backend server). The client communicates over a (proprietary) request-response protocol with a dedicated server process. We have successfully used the C SDK to track these requests are business transactions. Now we would like to see a metric of concurrent sessions. What's the best way to implement this? Would it require using Analytics to periodically run an ADQL query on "distinct session ids"?
... View more
Now that ticket that you have raised regarding this issue is closed,i will post the gist of your discussion with Robb and me here for any future references.
In short C++ SDK is thread safe but not process safe. If your fork creates a new process, you can not access the SDK. If you are trying to implement the SDK on a forked child process, then you will need to initiate the SDK from within each forked process separately (including the appd_sdk_init() call), and all API calls must remain within the same process, you can not share BT or ExitCall handles across processes.Currently to determine whether the future SDK API calls should be accepted or not,it validates if the existing pid is the same as the one which issued appd_sdk_init call . But then if you try to call appd_sdk_init() call from a child process as well it might cause some corruption as SDK implements ZeroMQ messaging in the globally shared process space.Within each instrumented thread, the C/C++ SDK API uses ZeroMQ message buffers (and its underlying Unix sockets) to communicate to the Proxy task.
It should be possible to run two (or more) separate processes, both using the SDK API calls, provided they run completely independently of each other (i.e. do not share handles across process spaces). In other words, as long as each process makes its own appd_sdk_init() call, and use only handles created within that process space/sdk contex, (i.e. that they never share any handles between processes) then you should be able to implement the SDK in a forked process architecture.
Feel free to reach out to us in case you have more questions.
Thanks and Regards,
... View more