Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Remote Cache Fetching

Status
Not open for further replies.

cathy0709

IS-IT--Management
Aug 18, 2009
13
CA
Hi. We have Livelink 9.7.1 environment with a Remote Cache server. The satelite link is 1MB. When users on the Remote Cache box try to open documents (example 29MB), it timesout. Is there anyway to stop the timeout?

Thanks,
Cathy
 
is the document on the RC a first time pull or a pre-arranged(scheduled) pull?

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
 
What access method are you using for LL, .exe, .dll or the servlet ? what is your network load ? how busy are the LL servers ?

Greg Griffiths
Livelink Certified Developer & ECM Global Star Champion 2005 & 2006
 
The document on the RC would be a first time pull for that version. We do scheduled updates every evening on select documents. But this particular document was for example updated this morning and then tried to be pulled across the satelite this afternoon.

We are using LL.exe. Network load isn't high. The Primary LL server is used approximately 200 users - searching, adding etc.
 
A first pull always will be slower as the RC server has to cache the document from the Primary server.Look at the thread timings logs on that particular sequence on the primary location and see if on the remote site you are extremely challenged on latency.It is not easy to do this as it involves a lot of network tracing.packets etc.What I said is the working behind or design of RC.RC looks faster to a RC user uploading a big file and looks faster when downloading a RC cache file.First time pulls are just like you pulling it from livelink or it has to cross geographical paths.

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
 
Thanks for the reply. I had some network guys look at the tracing packets and everything seems fine. There isn't any high amount of network traffic. I'm not convinced that it's network thing - it may be a configuration problem.
 
Uh Oh sorry that wasn't it do you get any help out of OT support.I know from my earlier problems with RC they seemed to know what to make it all working better like increase timeouts and stuff.I remember but don't have the exact but if you search the KB for RC info there seems to be a timeout setting I was advised to change.But that would be the time the RC client would wait for the livelink server something like that.

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
 
So there is a setting on the RC server side where you can include an acceptTimeout=15000 under the sockserv section of RC ot.ini file, do not be confused with timeout=5000 default value.Include one extra line and test, i am also running into similar issue but this parameter has not resolved our issue.
If i get it working by other LL config, ntk tuning etc will keep here posted.
Cheers,
Mukesh Giri
 
Hi Cathy:
Did you get a chance to use this timeout parameter in your RC ot.ini file?
Has it fixed the time-out issue?
Also can you check with your network team if they are having your RC and the sever to which the RC is pointing to is being hosted utilizing Riverbed wan accelerators?
Let me know how it goes with you.
Thanks,
Mukesh
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top