I'm a bit wondering for some time and today thought about something which would improve the performance of one of our integrations (communicating with Integrity using the Java API), if this wouldn't be the case. There're notes in the Java Doc of the Integrity Java API (mksapi.jar), like this:
"Note: The MKS implementation of this interface is not thread safe and it is not recommended that multiple threads be used to access this interface."
(From the com.mks.api.response.Response interface)
So, the problem is, if I want to reliable access the methods of a PTC/MKS implementation of the Response interface (which is the usual thing returned by CmdRunner.executeCommand(), I need to build my whole application as a single-threaded, sequenciel application. This is, at least from performance point of view, not the best idea in all cases. Consider this case:
We've an integration which periodically requests information from Integrity and performs tasks based on the results of a query (actually it's a "test client", which executes test cases and reports back the test result). The idea would be to execute the tests in a pool of some threads instead of in a sequenciel order (like it is implemented now), and also report back the test results in an asynchronus task, once the execution of a test case finished. However, this is not possible, as the MKS api is marked as being not thread-safe for most interfaces.
The question now is: Does anyone know, why? And, does anyone know, if this will change in the (near) future?
Re: Integrity Java API implementation not thread-safe
I think I'm running into this issue also but with the managed API with C#. We have large projects that I download into a custom client used for test execution. It takes about 7ish minutes for a certain project we have. Using multiple connections, I can get it down to about 3 minutes but 75% of the time, I get a heap corruption exception on the response. I'm thinking it's for the same reason. Instead of dealing directly with threads, I work with tasks (TAP). The tasks that are created can end up in a different thread though if the task scheduler tells it to. I gave up on trying to implement multiple connections for download for now but I'm hoping someday there will be an update that will fix this.