This is definitely possible what you are calling thread is probably another instance of your program in reality this is what happens I will show a simple illustration

FE1 Configure 5 Threads
FE2 Configured 5 Threads

Your client program asks the API to do something
Assume it was received by FE1 Thread1 it will forward to OTDS and return the authentication token so far everything will work.
You got what you needed from API again you invoke another API call chances are it will go to FE1 Thread 2 again it will work because your call contains
the session object... or a nonexpired token

Now think what would happen in this cycle if it went to FE1 Thread1 it sees the auth token it will discard it because the token when parsed
will reveal the IP address of FE1 and you are coming from FE2...

So what can you do?
Most people relax the cookie restrictions on Livelink Content Server to say don't use the IP address to validate me
Or some organizations put sticky algorithm on load balancer so a program always hits the same server

In long-running programs using CWS the Client developers pseudo code should be something like this as LL does not address it for you

I have to Call an API and I have an AuthToken
I should see if the TTL has expired if it has re-authenticate...

Also, Attachment Object of Docman is a very bad idea the better way is to rewrite that code using ContentService methods.





Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010
http://www.tek-tips.com/faqs.cfm?fid=2884
http://www.linkedin.com/in/appunair
http://www.livelink.in

Let me clarify my issue, I have configured 4 threads to download the document from the Content Server. The main thread is responsible for making the connection with the Livelink server (using RCSAuthenticationOTDS), set the authentication token to the SOAP header (OTAuthentication), and initializing the ContentService & DocumentManagement web services object. After getting the authentication token the 4 threads are created & running concurrently to download the document from the Content Server by sharing the same ContentService & DocumentManagement web services object. When threads run concurrently then I got the OTDS Error or Socket connection closed exceptions for some method calls while others running perfectly.
But If I put the download document method inside the synchronized block then everything is working fine. In this case, only one thread is allowed to download the document while others are waiting for their turn. See below the download document code.

String contextId = fDocMan.getVersionContentsContext(nodeId, nodeVersion); // Here I got the OTDS or Socket error
DataHandler dataHandler = fContent.downloadContent(contextId);
out = new FileOutputStream(fileDir);
dataHandler.writeTo(out);

Also I am running a single instance of the program with multiple threads. So the IP Address of the client is same and the authentication/connection is made with the main thread and the child threads uses the same shared objects (fDocMan & fContent) to download the document which is initialized by the main thread.

The threads I mention are basically Livelink Threads. Usually, a Livelink server is configured between 8-32 threads, and for redundancy, a load balancer is used hence what a thread in one server contains has is the LLCookie which is the AUTH that you get from either a Livelink Auth or OTDS Auth. This is not freely exchangeable with another Livelink Server thread. You will not run into this difficulty with the Livelink REST API because every REST API Call will give you a refreshed token so you do not have to look if the token is valid before calling the API.
In a multiserver environment, either relaxing the security params of livelink or setting sticky on LB will solve the authentication problem.

Not to be confused with Java threads C# threads and so on.

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010
http://www.tek-tips.com/faqs.cfm?fid=2884
http://www.linkedin.com/in/appunair
http://www.livelink.in