When you have a cluster of say 3 Nodes then each of them can have differing setup (although many admins et up Cs's identically).The most common problem in such a deployment is to set the
Configure Security Parameters inconsistently
This is how a default install keeps it
In absolute layman understanding(there is a help on that page) it just means that if I logon to with my browser to that my client IP address the 4 Octets will be in that cookie and hence I can logon without re authentication so long as the TTL is valid. The last pull down in that says "Do not use IP address for authentication" means what it it means.
When you call a REST API you first authenticate for a token with a service like OTDS (OTDSToken) and many programmers exchange that to a OTCSToken ( /api/vi/auth) if you are in a bad cluster setting then that token is valid only to the server issuing it perhaps 1 of the 3 servers.
So you have an option of running your code with OTDSToken that will be less trouble some it will be encashed by the server for a valid ticket internally.
While I don't know if your problem is regarding authentication but fixing your setup most likely will help .If you bombard livelink servers with work it cannot handle then also you will run into problems.
Thank you for this information, I will check this setting and see if it makes a difference. What code does for load-balancing is I have an array of OTDS and OTCS URLs, then I launch each thread alternating between each OTCS/OTDS server. So every request gets its own token from OTDS/OTCS (alternating between servers), but definitely using the same IP. Can I get multiple tokens this way or does my other tokens get erased?
Hmm, I was told I had to get an OTCS ticket from OTCS with the OTDS token. I'm using "OTDSTicket" and "OTCSTicket" as headers for these tokens.
EDIT: I was mistaken, I have updated my code now to not get an OTCS Ticket. Thank you! WIll do more tests.
Just want to say THANKS! Using the OTDS ticket instead fixed my issues! It is working beautifully fast now!
Thanks! Re-using the OTDS ticket is what I'd ideally want to do (and what I was doing), but my script's threads don't have access to the other threads data. Basically, I'm reading the file plan from eDOCS DM, recreating it as a folder structure in Content Server, and then migrating all documents, metadata and permissions. I tried using 1 OTDS token per file part, but we have some file parts with 60-75K documents and so the token expires.
Do you know how to extend the OTDS token time? I would ideally set it super high during the migration and then set it back to its default, if possible.
I am not getting what you mean by other thread data
if I were to look at it via psuedocode
Got OTDSTicket ->Send to FE1->N ->Did it work ->No Get new OTDS->Update Central OTDSTicket variable
This is that variable
BTW the 7.8 hrs will not be useful because if CS says expire cookie in 30 mins from last request i am not sure if it will honor the 28200 in which case I don't know what it will go by.
I didn't think of this and maybe this is how you should work.
Every call to CS REST API returns you a refreshed token, they designed it because you can chain it so the question of expiry doesn't come to play.
