on 03-02-2016 3:11 PM
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
|
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
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
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.
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
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 |
<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" />
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
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" />
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
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.
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.
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
Robert,
One statement from our mobile team claims the following based on all our data above:
~~~~~~~~~~~From mobile dev team~~~~~~~~~~~
~~~~~~~~~~~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
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"/>
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
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
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)
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
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~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~``
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
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
User | Count |
---|---|
80 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.