cancel
Showing results for 
Search instead for 
Did you mean: 

Agentry Session Timeout

Former Member
0 Kudos

I have an issue with loading the agentry application on a mobile device. The work manager 6.3 application is large and is taking the device a long time to load. Before the load can complete the server disconnects the client. The server disconnects the mobile connection after 5 minutes. In the log I can find the session timer and the disconnect. Where can this 5 minute session timeout be changed?

2016 03 01 16:34:15#0-500#INFO#System.out###Thread-18076#########SessionTimer::run::Reset timer. |

2016 03 01 16:34:15#0-500#DEBUG#com.syclo.agentry.User.TESTTECH1###Thread-18076#########SessionTimer::run::Session timer sleeping for 60 seconds. |

2016 03 01 16:35:15#0-500#DEBUG#com.syclo.agentry.User.TESTTECH1###Thread-18076#########SessionTimer::run::Session timer for user: TESTTECH1 ending. |

2016 03 01 16:40:13#0-500#DEBUG#com.sap.mobile.platform.server.agentry.console###Agentry SAPWM6.3 Worker Thread#########Received Rule Definition Request(209), 21, 15, testtech1, 380869/1886, 4:38:34PM/4:38:34PM |

2016 03 01 16:40:13#0-500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-8#########IOExceptions are normal, ignored javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset

at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1529)

at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1541)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)

at org.apache.coyote.http11.upgrade.UpgradeBioProcessor.write(UpgradeBioProcessor.java:61)

at org.apache.coyote.http11.upgrade.UpgradeOutbound.write(UpgradeOutbound.java:44)

at org.apache.catalina.websocket.WsOutbound.close(WsOutbound.java:354)

at org.apache.catalina.websocket.StreamInbound.closeOutboundConnection(StreamInbound.java:200)

at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:166)

at org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:88)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:812)

Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection reset

at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)

at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)

at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1894)

at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1858)

at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1803)

at sun.security.ssl.AppInputStream.read(AppInputStream.java:116)

at org.apache.coyote.http11.upgrade.UpgradeBioProcessor.read(UpgradeBioProcessor.java:85)

at org.apache.catalina.websocket.WsFrame.blockingRead(WsFrame.java:170)

at org.apache.catalina.websocket.WsFrame.<init>(WsFrame.java:97)

at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:220)

at org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java:72)

at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:153)

... 7 common frames omitted

Caused by: java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:209)

at java.net.SocketInputStream.read(SocketInputStream.java:141)

at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)

at sun.security.ssl.InputRecord.read(InputRecord.java:503)

at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)

at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:918)

at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)

... 13 common frames omitted

|

0 Kudos

Hello everyone,

has this thread ended up with something?

We got stuck with all these timeouts as well.

0 Kudos

Well, has anything become known?

former_member34
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi there,

You have a question and need help by the community? Instead of posting into an old question thread, it is more helpful for you, if you create your own question. Here is how to get started:

  1. Learn about asking and answering questions in SAP Community with this tutorial: https://developers.sap.com/tutorials/community-qa.html
  2. Ask your detailed question here: https://answers.sap.com/questions/ask.html
  3. Wait for a response.

That's it. Thank you!

Best regards

Jennifer

Your SAP Community moderator

Accepted Solutions (0)

Answers (1)

Answers (1)

mark_pe
Active Contributor
0 Kudos

Work Manager 6.3 is based on SMP 3.0. Most of the application configuration is now in the SMP 3.0 Cockpit. If you take the old Agentry.ini data which you used to configure the time out, most of the time out now are in the Backend Section of the SMP 3.0 Cockpit or the App Configuration settings.

Also if you have transmit configuration setup specified in your Eclipse Agentry editor, the stay connected to system has an option to be enabled. If you do not have this enabled, the hard coded time out parameter is 5 minutes. 

Hope this helps.

Mark Pe
SAP Platinum Support Engineer

Former Member
0 Kudos

We changed every timeout parameter in the SMP cockpit to very high numbers. None affect the socket disconnect timeout. The timeout is happening in the ssl socket connection

javax.net.ssl.SSLException: Connection has been shutdown

The application is not even loaded. This is happening on the initial application load. The process goes through the the CT and DT loads. Then it starts downloading the application definitions.  Exactly 5 minutes after the application definitions start the server closes the socket.

In the ATE the application loads completely because it is fast enough to load before the timeout. The windows ce device loads very slowly and only gets through 1/3 of the rules before the socket is closed.

During the initial application load would the stay connected actually be in affect before the transmit config is even loaded? The socket closing seems to be coming from the server side. Why would the client close the socket before the application is loaded?

mark_pe
Active Contributor
0 Kudos

Robert,

What is your version of SMP 3.0 server runtime? Are you running as Dev Server or Prod server? How many application do you have loaded? Could it be memory related (what did you define in the JVM setting in the cockpit)? Are you using SMP 3.0 runtime PL01 or PL02+ (Some memory enhancement on PL02 or higher)?

So it works in ATE because it is fast but the WinCE fails? So you are suggesting a time out tied to Pocket PC and it is exactly 5 minutes?

Worst comes to worst you may need to check tracing on your HTTP either from your proxies time out settings or firewall (Sometimes on delay they can shut down connection) without the server knowing it.Are you testing by means of VPN or are you in the same local environment? If you are in a different environment (developing at home) while connecting to the customer you may try to see if you can duplicate in the same network.

Regards,

Mark Pe
SAP Platinum Support Engineer

Former Member
0 Kudos

SMP 3.0 SP10 PL05

Same problem on development server and production server install. There is no VPN. It is a direct connection to the server. Again the socket is being closed by the server not the client. There is no connection to SAP at this point it is only downloading the application definitions from the server to the client. SAP is on the same network as SMP server. There is nothing between client, smp, or sap.

SAPWM6.3 Worker Thread#########Received Rule Definition Request(209), 21, 15, testtech1, 380869/1886, 4:38:34PM/4:38:34PM |

What is happening is that once the client starts its download of definitions it is disconnected in exactly 5 minutes. If the client finishes before 5 minutes all is good. If it does not, it gets Error 11 unexpected disconnect from server.

2016 03 01 16:40:13#0-500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-8#########IOExceptions are normal, ignored javax.net.ssl.SSLException: Connection has been shutdown


Tomcat server is shutting down the connection.

When you watch the windows ce client it loads extremely slow. You can read line by line each item it loads. The windows ce client cannot load the entire work manager application in 5 minutes time.

Former Member
0 Kudos

Also the transmit configuration Inactivity timeout is set to 8 hours. That is not affecting this disconnect.

mark_pe
Active Contributor
0 Kudos

Robert,

Hi. Based on your comments above and the exact error:

Tomcat server is shutting down the connection. <--


Reference # http://service.sap.com/sap/support/notes/2172104


Agentry is a bundle inside SMP 3.0.  The control that we have for time out or inactive time out will not apply here within any of the SMP 3.0 cockpit features.


This error is before the Agentry side (code - confirmed with Agentry dev) - not part of the Syclo code as SMP 3.0 consist of multiple team and this part is not the one in Chicago (or former Syclo).


I will see if I can find a colleague in SMP 3.0 who may know this timer within the batch script (I am thinking that the go.bat or go-service.bat may have some quick time out option somewhere in it but I'll try to see if I can find somebody who can confirm).


Best Regards,

Mark Pe

SAP Platinum Support Engineer





mark_pe
Active Contributor
0 Kudos

Robert,

From my colleagues they claim it is this section in the SMP 3.0 cockpit.  Try to play or increase this time out. Please share what yours look like.

Default HTTP 20000 time out.

Hope this is your issue.

Best Regards,

Mark Pe
SAP Platinum Support Engineer

Former Member
0 Kudos

Those settings are modifying the default-server.xml file for the tomcat config. Notice that the device connects to the 8081 SSL port. Not the 8080 HTTP port. From your screen shot you can see there is no timeout setting available for the SSL 8081 port.

Looking at the tomcat configuration guide you can see the connection timeout setting on that page is only available for HTTP not SSL. That connection timeout is in milliseconds so that is 20 seconds.

connectionTimeout

The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds). Unless disableUploadTimeout is set to false, this timeout will also be used when reading the request body (if any).

<Connector smpConnectorName="noSSL" port="8080" protocol="HTTP/1.1"

  maxThreads="250" connectionTimeout="20000" enableLookups="false"

  acceptCount="100" redirectPort="8081" server="SAP" compression="on"

  compressionMinSize="2048"

  compressableMimeType="text/html,text/xml,application/javascript,text/json,text/plain,application/json,application/atom+xml,application/atomsvc+xml,application/xml" />

  <!-- An Engine represents the entry point (within Catalina) that processes

  every request. The Engine implementation for Tomcat stand alone analyzes

  the HTTP headers included with the request, and passes them on to the appropriate

  Host (virtual host). Documentation at /docs/config/engine.html -->

  <Connector smpConnectorName="oneWaySSL"

  protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol"

  port="8081" maxThreads="200" scheme="https" secure="true" SSLEnabled="true"

  ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA"

  keyAlias="smp_crt" clientAuth="false" sslProtocol="TLS"

  sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" compression="on"

  compressionMinSize="2048"

  compressableMimeType="text/html,text/xml,application/javascript,text/json,text/plain,application/json,application/atom+xml,application/atomsvc+xml,application/xml" />

mark_pe
Active Contributor
0 Kudos

Robert,

Hi. Due to you are in that level (xml level), did you try to reuse the keyword connectionTimeout="20000"  within the <Connector smpConnectorName="oneWaySSL"...>?  To see if it will work manually?


So in essence see if you restart SMP 3.0 when you edit it if it will work.  Just because you are in test mode.  It may be that the SMP 3.0 cockpit team didn't expose it yet in the cockpit but it may be supported in that level.


Hopefully somebody in the SMP 3.0 cockpit or group can confirm.


Regards,

Mark

Former Member
0 Kudos

There is good reference here on the setting values for connectors in tomcat.

https://tomcat.apache.org/tomcat-7.0-doc/config/http.html

From the tomcat documentation connectionTimeout is only a setting in the HTTP connection and not the SSL connection. SSL connection has a sessionTimeout setting. The default is 24 hours.

sessionTimeout

The time, in seconds, after the creation of an SSL session that it will timeout. Use 0 to specify an unlimited timeout. If not specified, a default of 86400 (24 hours) is used.

There is nothing specified in the connector. It also uses a custom protocol.

<Connector smpConnectorName="oneWaySSL"

  protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol"

  port="8081" maxThreads="200" scheme="https" secure="true" SSLEnabled="true"

  ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA"

  keyAlias="smp_crt" clientAuth="false" sslProtocol="TLS"

  sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" compression="on"

  compressionMinSize="2048"

  compressableMimeType="text/html,text/xml,application/javascript,text/json,text/plain,application/json,application/atom+xml,application/atomsvc+xml,application/xml" />

Former Member
0 Kudos

What I was led to believe that the Agentry timeout should be controlling the disconnection. There is an Inactivity Timeout on the Application settings. That is set for 2 hours. Either that is the correct setting and it doesn't work or there is some other setting controlling the 5 minute disconnect.

mark_pe
Active Contributor
0 Kudos

Robert,

I'll see if anybody else can answer it from the SMP 3.0 (SMP 3.0 SP10 PL05 - Other team) with respect to the time out tied to that aspect of SMP (SSL and Port 8081 and the 5 minute time out). Hopefully they respond soon.

Just FYI: I discussed this with Agentry QA and Dev and all our test here worked for initial loading of definition for WinCE.    From Agentry dev, we even have initial loading of 15 minutes without issue from WinCE to SMP 3.0.  What is the device brand and OS? Why is it taking too long? Did you try another device?

Regards,

Mark

Former Member
0 Kudos

To clarify the 5 minute timeout does not include the loading of complex tables and data tables. During the loading of the of the table data the session timer will wake up and reset every 60 seconds.

2016 03 01 16:34:15#0-500#INFO#System.out###Thread-18076#########SessionTimer::run::Reset timer. |

2016 03 01 16:34:15#0-500#DEBUG#com.syclo.agentry.User.TESTTECH1###Thread-18076#########SessionTimer::run::Session timer sleeping for 60 seconds. |


Once the client starts receiving definition requests the session timer no longer wakes up and resets.


SAPWM6.3 Worker Thread#########Received Rule Definition Request(209), 21, 15, testtech1, 380869/1886, 4:38:34PM/4:38:34PM |


Instead the session timer wakes up and ends


2016 03 01 16:35:15#0-500#DEBUG#com.syclo.agentry.User.TESTTECH1###Thread-18076#########SessionTimer::run::Session timer for user: TESTTECH1 ending. |


5 minutes after that point the session is closed.


The device is a Motorola MC67. It takes a long time to load because there are a lot of screens images rules etc to load.


The only other device is the ATE. It loads fine.


mark_pe
Active Contributor
0 Kudos

Robert,

Let me ask the Dev assist team on the SMP platform side (non-Agentry) if they have any idea on this issue. Let me try to find them.

Regards,

Mark Pe

SAP Platinum Support Engineer

Former Member
0 Kudos

We also tried adding these to the Agentry.ini on the development SMP install.

[Server]

inactiveTimeout=600

[ANGEL Front End]

timeout=300

We set them to 7200 each. These settings used to be in the Agentry.ini before moving to SMP. 600 and 300 are the default values. What is interesting is the timeout=300 is the default socket timeout. That means in the agentry code the socket would be closed after 300 seconds or 5 minutes of inactivity. This is what seems to be happening. The inactiveTimeout seems to have been moved into the SMP cockpit, but this socket timeout is missing.

Putting these in the agentry.ini did not result in any change.

mark_pe
Active Contributor
0 Kudos

Robert,

I am working with our global mobility development team to see if they can answer this question (The teams are all located around the world. We need to make sure that they have seen the question. So I need to give them time). If they respond soon I can update this thread.  We also noticed internally that an SAP incident was created. We will also update it as well or hand it over to the needed team if we do not get a fast enough response.

Thanks for your patience and we will try to get the answer soon.

Best Regards,

SAP Mobile Support Team

mark_pe
Active Contributor
0 Kudos

Robert,

One statement from our mobile team claims the following based on all our data above:

~~~~~~~~~~~From mobile dev team~~~~~~~~~~~

  • The setting screen values are only for SMP outbound connections only (connections initiated by SMP 3.0)

  • The user must change the settings for the listener port 8081.
  • That's the setting in the default-server.xml that was already pointed out

~~~~~~~~~~~end~~~~~~~~~~~~~~~~~~~~~~~~~


I am currently asking for more details on this statement.  So I guess this is similar to what I suggested above where while you are in the xml level to see if you can work with the settings.  But the key in the statement above is to setup or change the settings for the listerner port 8081.

Regards,

Mark Pe
SAP Platinum Support Engineer

Former Member
0 Kudos

If we modify the settings on the page shown. Change the port to 8089 which is the listener port for the agentry server. The default-server.xml is changed. That page configures the listeners for SMP. Also note the default sessionTimeout for the listener is 24 hours based on Tomcat documentation.

<Connector SSLEnabled="true" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA" clientAuth="false" compressableMimeType="text/html,text/xml,application/javascript,text/json,text/plain,application/json,application/atom+xml,application/atomsvc+xml,application/xml,       application/opensearchdescription+xml,application/rss+xml,application/html,application/css,application/js" compression="on" compressionMinSize="2048" keyAlias="smp_crt" maxThreads="200" port="8089" protocol="com.sap.mobile.platform.coyote.http11.SapHttp11Protocol" scheme="https" secure="true" smpConnectorName="oneWaySSL" sslEnabledProtocols="TLSv1.2,TLSv1.1,TLSv1" sslProtocol="TLS"/>

mark_pe
Active Contributor
0 Kudos

Robert,

Hi. I will forward your question and respond to the dev team. The internal issue will also be forwarded.  Thanks for your patience here. Let me do the technical write up as I need to take all the data above and create a quick write up of the issue today to forward it to them. So either the dev team will update this thread or they will update the internal incident opened in SAP.

Best Regards,

Mark Pe
SAP Platinum Support Engineer

mark_pe
Active Contributor
0 Kudos

Robert,

One more thing:

The dev team specified the following:

~~~~~~~~~~~From dev team~~~~~~~~~~~

1) The customer should edit the existing oneWaySSL connector and add the keyword connectionTimeout="..." See https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation for a full list of available settings

~~~~~~~~~~End~~~~~~~~~~~~~~~~~~


Not sure if you confirmed that you have tried this.  All I see above are statement from the documentation.


Best Regards,

Mark Pe

SAP Platinum Support Engineer

Former Member
0 Kudos

we modified the default-server.xml and added connectionTimeout="-1". According to the documentation that results in infinite timeout.

The runs after that change resulted in a longer runtime before the connection was closed. The device loaded more of the application. The runtime after the session timer ending is 13 minutes. This change did create a different error message.

2016 03 07 13:31:48#0-500#DEBUG#com.syclo.agentry.User.TCE###Thread-9047#########SessionTimer::run::Session timer for user: TCE ending. |

2016 03 07 13:31:48#0-500#INFO#System.out###Thread-9047#########SessionTimer::run::Session timer for user: TCE ending. |

2016 03 07 13:44:58#0-500#DEBUG#com.sap.mobile.platform.server.agentry.console###Agentry SAPWM6.3 Worker Thread#########Received Rule Definition Request(209), 21, 14, tce, 323961/1596, 1:41:01PM/1:41:01PM |

2016 03 07 13:44:58#0-500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-8#########SocketExceptions are normal, ignored java.net.SocketException: Connection closed by remote host

at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1543)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)

at org.apache.coyote.http11.upgrade.UpgradeBioProcessor.write(UpgradeBioProcessor.java:61)

at org.apache.coyote.http11.upgrade.UpgradeOutbound.write(UpgradeOutbound.java:44)

at org.apache.catalina.websocket.WsOutbound.close(WsOutbound.java:354)

at org.apache.catalina.websocket.StreamInbound.closeOutboundConnection(StreamInbound.java:200)

at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:166)

at org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:88)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:812)

mark_pe
Active Contributor
0 Kudos

Robert,

So you have a different error so this is something new.  13 minutes difference so this may be another time out in the works.

~~~~~~~~~~Before changes Error~~~~~~

2016 03 01 16:40:13#0-500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-8#########IOExceptions are normal, ignored javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset

~~~~~~~~~~~~End~~~~~~~~~~~~~~~~~~

~~~~~~~~~~After changes Error~~~~~~~~


500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-8#########SocketExceptions are normal, ignored java.net.SocketException: Connection closed by remote host


~~~~~~~~~~~~~End~~~~~~~~~~~~~~~~~~~


IOExceptions are normal - SocketException:Connection reset


VERSUS 


SocketExceptions are normal - Connection closed by remote host.


So from reset on Socket it is now closed by remote host.


Wondering if the SocketException - Connection closed by remote host is now tied to the actual socket time out.


There are other options in the same link:


https://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation


keepAliveTimeout - The number of milliseconds this Connector will wait for another HTTP request before closing the connection. The default value is to use the value that has been set for connectionTimeout or use a value of -1 to indicate no timeout.


maxConnections - The maximum number of connections that the server will accept and process at any given time.


maxThreads - The maximum number of request processing threads to be created by this Connector.


Java TCP socket Attributes:

socket.soTimeout - This is equivalent to connectionTimeout.




I am wondering if there are additional setting we can setup that is also in the link above. The new error keywords are "Socket Exception" - something wrong with Socket and Connection closed or Java.net.SocketException.


In the Cockpit there are other areas that may map to the file.


Are there issues with number of threads?  Or Socket connection timeout?


~~~~~~~From log~~~~~~~~~~~

2016 03 07 13:31:48#0-500#INFO#System.out###Thread-9047#########SessionTimer::run::Session timer for user: TCE ending. |

..

..

..

.. 13 minutes later data came to receive Rule Definition Request

..

..

2016 03 07 13:44:58#0-500#DEBUG#com.sap.mobile.platform.server.agentry.console###Agentry SAPWM6.3 Worker Thread#########Received Rule Definition Request(209), 21, 14, tce, 323961/1596, 1:41:01PM/1:41:01PM |

016 03 07 13:44:58#0-500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-8#########SocketExceptions are normal, ignored java.net.SocketException: Connection closed by remote host

~~~~~~~~~end~~~~~~~~~~~~~

13 minutes wherein it states Session timer for user TCE is ending but the first Receive of the Rule from the server is 13 minutes later then the connection closed?

What does your Cockpit SETTING->SYSTEM is set for?

Regards,

Mark



Former Member
0 Kudos

Here are the settings we have set to this point.

default-server.xml - oneWaySSL connection has connectionTimeout="-1" maxKeepAliveRequests="-1" socket.soTimeout="-1"

web.xml - session timeout is 40 minutes

Admin Cockpit changed settings for the online proxy connection timeout=600000 , socket connection timeout = 600000, connection pool idle timeout = 600000.

From the smp log the only thing that is stored is the requests for definitions between the session timer ending. I took out all the log lines to try to keep the thread readable.

Here is the excerpt from the last run with all those settings defined.

~~~~~~~~~~~~~~~~~log~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2016 03 08 09:16:16#0-500#DEBUG#com.sap.mobile.platform.server.agentry.console###http-bio-8081-exec-1#########Received Action Definition Request(208), 21, 13, tce, 341755/1653, 9:15:04AM/9:16:16AM |

2016 03 08 09:17:38#0-500#DEBUG#com.sap.mobile.platform.server.agentry.console###Agentry SAPWM6.3 Worker Thread#########Received Rule Definition Request(209), 21, 14, tce, 341244/1664, 9:16:16AM/9:16:16AM |

2016 03 08 09:17:38#0-500#DEBUG#org.apache.coyote.http11.Http11Protocol###http-bio-8081-exec-1#########IOExceptions are normal, ignored javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Connection reset

at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1529)

at sun.security.ssl.SSLSocketImpl.checkWrite(SSLSocketImpl.java:1541)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:71)

at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)

at org.apache.coyote.http11.upgrade.UpgradeBioProcessor.write(UpgradeBioProcessor.java:61)

at org.apache.coyote.http11.upgrade.UpgradeOutbound.write(UpgradeOutbound.java:44)

at org.apache.catalina.websocket.WsOutbound.close(WsOutbound.java:354)

at org.apache.catalina.websocket.StreamInbound.closeOutboundConnection(StreamInbound.java:200)

at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:166)

at org.apache.coyote.http11.upgrade.UpgradeProcessor.upgradeDispatch(UpgradeProcessor.java:88)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:812)

Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection reset

at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)

at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1937)

at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1894)

at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1858)

at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1803)

at sun.security.ssl.AppInputStream.read(AppInputStream.java:116)

at org.apache.coyote.http11.upgrade.UpgradeBioProcessor.read(UpgradeBioProcessor.java:85)

at org.apache.catalina.websocket.WsFrame.blockingRead(WsFrame.java:170)

at org.apache.catalina.websocket.WsFrame.<init>(WsFrame.java:97)

at org.apache.catalina.websocket.WsFrame.nextFrame(WsFrame.java:220)

at org.apache.catalina.websocket.WsInputStream.nextFrame(WsInputStream.java:72)

at org.apache.catalina.websocket.StreamInbound.onData(StreamInbound.java:153)

... 7 common frames omitted

Caused by: java.net.SocketException: Connection reset

at java.net.SocketInputStream.read(SocketInputStream.java:209)

at java.net.SocketInputStream.read(SocketInputStream.java:141)

at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)

at sun.security.ssl.InputRecord.read(InputRecord.java:503)

at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:961)

at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:918)

at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)

... 13 common frames omitted

|

~~~~~~~~~~~~~~~~~~~~~~end log~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~``

mark_pe
Active Contributor
0 Kudos

Robert,

Thanks for making this clear after all your settings.  Let me forward this information to the SMP 3.0 team to respond. I'll update this thread once I find out more tied to your latest changes. Please stay tune as my SMP 3.0 team may be in a different time zone for them to respond. I need them to check the message when they go online.

Best Regards,

Mark Pe

SAP Platinum Support Engineer

mark_pe
Active Contributor
0 Kudos

All,

Tried pinging development again on their response today (US Central 1:55PM). Hopefully an update is heard by tomorrow.

Best Regards,

Mark Pe
SAP Platinum Support Engineering

mark_pe
Active Contributor
0 Kudos

Robert,

I believe we have to push the internal SAP incident to development team so they can schedule an assigned person to this task.  Action item, I have the incident in my queue but I need you to attached the log files of your server including the agentry log files during the time of your test to the incident (add any notes you want to add).  I am assuming the only opened incident in SAP Agentry or Work Manager right now is this particular issue with the same exact error for company F*. I believe this is yours, right?  Please attach the logs now so we can move this to development.

Thanks for your patience.

Best Regards,

Mark Pe
SAP Platinum Support Engineer

Former Member
0 Kudos

Hi Mark,

This is Nirali from Flowers, I am working with Robert for troubleshooting this issue. I have Logs ready to be shared, but the attachment is to big to be attached here.

Is there a link to fileshare so I can share the logs with you?

Thanks

mark_pe
Active Contributor
0 Kudos

Nirali,

I will put the link in the incident inside SAP. Expect it in there. After this, we can push this to the SMP 3.0 runtime server dev team.

Best Regards,

Mark Pe
SAP Platinum Support Engineer