GetPeerInfo getpeername failed with error. Transport endpoint is not connected

Pablo Garcia Diaz

Hi all,
We have several instances livelink 971 receiving thousands of requests via java LAPI .
Sometimes we find this error in our logs with a few fetch operations :

KBSDStream :: write failed ** **
KBSDSocket :: GetPeerInfo getpeername failed with error = Transport endpoint is not connected .
 

Those requests takes a huge amount of time to be processed (our average time is less than 1 second)

We think it may be due to communication errors with NFS target .
Has anyone encountered these errors ?
How can we confirm the source of the error ?
Could it be solved changing any Livelink's parameter ?

 

There's an example from our thread log:

02/28/2013 10:22:12 [1828334468] Processing Request on socket 59a9860
Jue Feb 28 10:22:12 2013
FilePath = '//fichtemcomp/pr/digrecup/ kjid/kgpe/0900/0182_reg_datos. cod_oficina/0001/968/316968// 6576281'
NodeID = '6576281'
VersionID = '1'
VolumeID = '-2000'
_ApiName = 'FetchVersion'
_ClientVersion = '9.7.1'
_ConnectionName = ''
_Cookie = ''
_DomainName = ''
_ImpersonateUserDomain = ''
_Request = 'llweb'
_UserName = 'LIVELINKNKGPE'
_UserPassword = 'XXXXXXXXXX'
_LLENVIRON_ASSOC is Undefined
[APIDispatchCBScript.Execute] was called 
Recommender watching is disabled
**KBSDStream::Write FAILED **
Jue Feb 28 10:52:24 2013 - 35063293 Func=lapi.FetchVersion Timing: 366.130 -335.-18 1812.465
KBSDSocket::GetPeerInfo getpeername failed with error = Transport endpoint is not connected
A<1,0,'ApplCtx'='\'N\'',' EndClock'=1! 522060,'EndMicro'=1493317792,' EndTick'=35063293,'ExecTime'= 1812465,'QueueDepthIn'=0,' QueueDepthOut'=0,'QueueTime'= G0,'StartClock'=1155930,' StartMicro'=1828336456,' StartTick'=33250828,'Timing'=' -335.-18','TimingClock'='366. 130','TimingTicks'='1812.465', 'XpostX_Number_of_Delete_ Statements'=0,'XpostX_Number_ of_Insert_Statements'=0,' XpostX_Number_of_Other_ Statements'=0,'XpostX_Number_ of_Rows_Fetched'=0,'XpostX_ Number_of_Select_Statements'= 10,'XpostX_Number_of_Update_ Statements'=0,'XpostX_Total_ Execute_Time'=22,'XpostX_ Total_Fetch_Time'=11,'XpostX_ Total_SQL_Statements'=10,' XpostX_Total_SQL_Time'=33,' XpostX_Total_SQL_Time_Logged'= 39>
**KBSDStream::Write FAILED **
**KBSDStream::Write FAILED **
02/28/2013 10:52:24 [3640807232] Done with Request on socket 59a9860

 

 

Thanks a lot for your suggestions,

Pablo

Appu_Nair1

Livelink and sockets are finite in a situation so some best practices for loading needs to be adhered I have not seen the exact error before but my guess is you are stretching the limit of everything.When a lapi call is performed like go to EWS a thread ( 5 by default) has to perform it on a instance.Lapi will be a chain of calls like 'getnode','fetchversion' so all these threads are perfoming stuff for you.On top of it if this livelink server is also servicing user requests like in webgui stuff livelink treats all of them as FIFO.So when we design massive loading apps so we designate a bunch of livelink instances as for LAPI,another bunch for OI,another bunch for users,another bunch for chores such as agents/notification/agents etc.But all these can work only if your database server also is very fast and not saturated.Only looking at your livelink health(no easy task so don't ask) can you really do something

Here's an OT article that I have seen giving you some break on windows TCP/IP stack

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=3500936&objAction=ArticleView

When I do Lapi things I anticipate  a possible failure so the unit of work I divide as one transcation.My one transaction could be a bunch of lapi things.So if that transaction fails I would re-attempt.There is  no implicit roll backs so you would in your code write what the cleanup is when you fail.My colleague and friend Ossie Moore has written Lapi applications(oscriptadventures.com) that accounts for possible failures and re-attempting .Kind of makes the lapi programmers life easy.

This is very similar to the Document Pipeline for LES which uses the pipeline concept .The pipeline submits one order marks them good or error.All the errors can be re-processed.Think if you have 5 pipeline servers these five servers are firing lapi commands marking things gone wrong.It makes bulk loading admins'  life easier as they have instructions to re-process things in error.