[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] PIRUS plugin issue?



I?d appreciate hearing whether anyone using the PIRUS plugin has seen anything similar to the following, or from anyone else with wisdom to offer ?
I have noticed that netstat on our eprints service shows many connections to 54.72.175.35:80 in CLOSE_WAIT state, originating from instances of the httpd process (see below) and that these connections take a long time to get to LAST_ACK and then stay in that state for a long time. If I understand what I read correctly, CLOSE_WAIT occurs when the remote end has requested that the TCP connection be closed (sent a FIN packet), to which the local protocol stack has responded with an ACK, and is then waiting for the local process with the connection open to close it.
54.72.175.35 is an Amazon AWS VM that appears to host a number of services but it appears most likely that the service of relevance here is http://www.jusp.mimas.ac.uk/<http://www.jusp.mimas.ac.uk/> and what we?ve got is the PIRUS plugin reporting each full-text download to the JUSP COUNTER application.
So it looks as to me as though the plugin is failing to close() the connection promptly on receipt of a close request from the JUSP COUNTER application.
I?m a dilettante when it comes to Perl and eprints code but, from glancing at the plugin code, I cannot see anything obviously amiss, so I?m guessing that the answer lies inside LWP::UserAgent or LWP::ConnCache as used by the plugin.
Does anyone else recognise this behaviour or have any suggestions on how to fix it, or can tell me I?m barking up the wrong tree?
This came to light because on a few occasions recently the NERC eprints service has become completely unresponsive with connections hanging and timing out and the logs recording many HTTP 500 errors and ?Software caused connection abort at /opt/eprints3/perl_lib/EPrints/Page.pm line 78.\n?.