Connection reset error in share.log

[skushnerenko]

Alfresco 5.2.0 share.log contains error on web service call.

How can it be fixed?

2017-10-04 12:41:36,602 INFO [org.springframework.extensions.webscripts.connector.RemoteClient] [http-apr-8080-exec-10] Exception calling (POST) http://localhost:8080/alfresco/s/remoteadm/create/alfresco/site-data/extensions/default-persisted-ex...
2017-10-04 12:41:36,605 INFO [org.springframework.extensions.webscripts.connector.RemoteClient] [http-apr-8080-exec-10] Error status 500 Connection reset
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
...

Fragment of my alfresco-global.properties 

dir.root=C:/ALFRES~1/alf_data

alfresco.context=alfresco
alfresco.host=172.31.0.145
alfresco.port=8080
alfresco.protocol=http

share.context=share
share.host=172.31.0.145
share.port=8080
share.protocol=http

[jpotts]

I think you're going to have to provide more context. The remoteadm end points are all marked with a lifecycle of "internal" so you shouldn't be calling them yourself. Is this error being generated by invoking some out-of-the-box action? If so, what?

[skushnerenko]

Thank you for the reply no special actions was invoked. But it was after instance migration to another machine.

Share.war module is not used in current installation, just alfresco.war for CMIS and WS calls.

So I hope, errors in share are not fatal for us.

[irvinborder]

This SocketException occurs on the server side when the client closed the socket connection before the response could be returned over the socket. For example, by quitting the browser before the reponse was retrieved. Connection reset simply means that a TCP RST was received. TCP RST packet is that the remote side telling you the connection on which the previous TCP packet is sent is not recognized, maybe the connection has closed, maybe the port is not open, and something like these. A reset packet is simply one with no payload and with the RST bit set in the TCP header flags. There are several possible causes.

• The other end has deliberately reset the connection, in a way which I will not document here. It is rare, and generally incorrect, for application software to do this, but it is not unknown for commercial software.
• More commonly, it is caused by writing to a connection that the other end has already closed normally. In other words an application protocol error.
• It can also be caused by closing a socket when there is unread data in the socket receive buffer.