I've wasted a couple of days now trying to track down an intermittent bug in the newly added Akka transport encryption.
NOTE: I have experimented with setting setIssueHandshake(true) on either or both of the server and the clients, but it doesn't help at all.
Our cipher spec tests a couple of different ciphers from different suites, to make sure that the settings we support actually works. However, the tests can sometimes pass 10 times, and then start failing every other test, it's truly SecureRandomly failing ;-)
Please do note that the test fails even on SHA1PRNG so it is clearly unrelated to the additional ciphers we provide.
The code that creates the SslHandler: https://github.com/akka/akka/blob/wip-ssl-unbroken-%E2%88%9A/akka-remote/src/main/scala/akka/remote/netty/NettySSLSupport.scala
The code that constructs the pipeline: https://github.com/akka/akka/blob/wip-ssl-unbroken-%E2%88%9A/akka-remote/src/main/scala/akka/remote/netty/NettyRemoteSupport.scala#L66
The tests: https://github.com/akka/akka/blob/wip-ssl-unbroken-%E2%88%9A/akka-remote/src/test/scala/akka/remote/Ticket1978CommunicationSpec.scala
The fall-back config (for what the test above doesn't override): https://github.com/akka/akka/blob/wip-ssl-unbroken-%E2%88%9A/akka-remote/src/main/resources/reference.conf
The keystore & truststore to use for the test: https://github.com/akka/akka/tree/wip-ssl-unbroken-%E2%88%9A/akka-remote/src/test/resources
The root exception that fails the test is:
**java.security.InvalidKeyException: No installed provider supports this key: (null)**
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at com.sun.net.ssl.internal.ssl.CipherBox.<init>(CipherBox.java:88)
at com.sun.net.ssl.internal.ssl.CipherBox.newCipherBox(CipherBox.java:119)
at com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.newCipher(CipherSuite.java:369)
at com.sun.net.ssl.internal.ssl.Handshaker.newReadCipher(Handshaker.java:410)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.changeReadCiphers(SSLEngineImpl.java:550)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1051)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:845)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:721)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:969)
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:670)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:333)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:214)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
And the "full" one is:
[ERROR] [06/20/2012 10:38:33.670] [remote-sys-4] [ActorSystem(remote-sys)] RemoteServerError#akka://remote-sys#localhost:59104] Error[
javax.net.ssl.SSLException: Algorithm missing:
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.changeReadCiphers(SSLEngineImpl.java:554)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1051)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:845)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:721)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:969)
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:670)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:333)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:214)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:91)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:373)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:247)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.security.NoSuchAlgorithmException: Could not create cipher AES/128
at com.sun.net.ssl.internal.ssl.CipherBox.<init>(CipherBox.java:99)
at com.sun.net.ssl.internal.ssl.CipherBox.newCipherBox(CipherBox.java:119)
at com.sun.net.ssl.internal.ssl.CipherSuite$BulkCipher.newCipher(CipherSuite.java:369)
at com.sun.net.ssl.internal.ssl.Handshaker.newReadCipher(Handshaker.java:410)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.changeReadCiphers(SSLEngineImpl.java:550)
... 17 more
Caused by: java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at com.sun.net.ssl.internal.ssl.CipherBox.<init>(CipherBox.java:88)
... 21 more
]
Not a bug in Netty, there was an unfortunate write-race between the application-level handshake and the SSL handshake. Worth to note is that setIssueHandshake(true) doesn't seem to be transparently handling the handshake as you need to manually back off writes until the handshake is completed.
whilst I've not seen exactly this exception, it's certainly the case that a javax.crypto.Cipher is not thread safe; I have an application where I finally tracked down a bug which was solved by synchronizing on the cipher:
cipher synchronized { cipher doFinal encryptedBytes }
Apologies if this is not the solution, but you posted a lot of code! (It's probably not exactly the same as the stack trace indicates that the issue is even getting a Cipher instance - but could this also need synchronizing?)
Related
I use StaticHandler in vertx-web to serve all static resource(css js mp4 files),
rootRouter.get("/static/*").handler(StaticHandler.create());
I use <video> tag to access the mp4 file in my page:
<video muted="muted" autoplay="autoplay" loop="loop" src="/static/img/factory.mp4"></video>
When I access the page which contained the mp4 file from Chrome, the server side will report a exception:
03:04:17.893 [vert.x-eventloop-thread-3] ERROR i.vertx.core.net.impl.ConnectionBase - Connection reset by peer
java.io.IOException: Connection reset by peer
at java.base/sun.nio.ch.FileChannelImpl.transferTo0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.transferToDirectlyInternal(FileChannelImpl.java:501)
at java.base/sun.nio.ch.FileChannelImpl.transferToDirectly(FileChannelImpl.java:566)
at java.base/sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:678)
at io.netty.channel.DefaultFileRegion.transferTo(DefaultFileRegion.java:130)
at io.netty.channel.socket.nio.NioSocketChannel.doWriteFileRegion(NioSocketChannel.java:362)
at io.netty.channel.nio.AbstractNioByteChannel.doWriteInternal(AbstractNioByteChannel.java:238)
at io.netty.channel.nio.AbstractNioByteChannel.doWrite0(AbstractNioByteChannel.java:212)
at io.netty.channel.socket.nio.NioSocketChannel.doWrite(NioSocketChannel.java:400)
at io.netty.channel.AbstractChannel$AbstractUnsafe.flush0(AbstractChannel.java:934)
at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.forceFlush(AbstractNioChannel.java:361)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:708)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:650)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:576)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
But when I use Firefox, there will be no problem.
And other static resources work normal, only the mp4 file will cause this exception.
Does anyone know what's going on? What should I do?
Connection reset by peer
is a response by the remote server (or firewall between them) stating that it will not proceed with completing this request.
So the other side has abruptly aborted the connection in midst of a transaction.
There are many possible reasons for this. It may well be a firewall denial, an SSL handshake failure, a VPN issue, slow internet, a proxy problem or even an HTTP failed request.
PS: this and this were helpful.
Updating the vert.x version in use could also print less of such messages as stated here.
we are facing CryptoException while decrypting the text in AEM 6.0 version. Actually one of our environment is having this issue. we dont have this issue in other environments. This issue is specific to only one environment. Literally we tried all the options.
Tried options:-
Deleted /etc/key folder in publish server and restarted Adobe Granite Crypto Bundle and restarted pub server too. But nothing is helped and still facing the same error.
Below is complete error message
Caused by: com.adobe.granite.crypto.CryptoException: Cannot convert byte data
at com.adobe.granite.crypto.internal.CryptoSupportImpl.unprotect(CryptoSupportImpl.java:160)
at com.pearson.aem.aemcore.hybris.services.CommerceServiceImpl.getExternalUser(CommerceServiceImpl.java:326)
... 136 common frames omitted
Caused by: com.adobe.granite.crypto.CryptoException: Failed decrypting cipher text
at com.adobe.granite.crypto.internal.CryptoSupportImpl.decrypt(CryptoSupportImpl.java:96)
at com.adobe.granite.crypto.internal.CryptoSupportImpl.unprotect(CryptoSupportImpl.java:157)
... 137 common frames omitted
Caused by: com.rsa.jsafe.JSAFE_PaddingException: Invalid padding.
at com.rsa.jsafe.JSAFE_SymmetricCipher.decryptFinal(Unknown Source)
at com.adobe.granite.crypto.internal.jsafe.JSafeCryptoSupport.getPlainText(JSafeCryptoSupport.java:326)
at com.adobe.granite.crypto.internal.jsafe.JSafeCryptoSupport.getPlainText(JSafeCryptoSupport.java:308)
at com.adobe.granite.crypto.internal.CryptoSupportImpl.decrypt(CryptoSupportImpl.java:94)
... 138 common frames omitted
Is there any config which we should cross verify?
Background: I have a web app that utilizes AngularJS, spring-mvc, and spring-rest for delivering the UI. I have a requirement to load balance using an Elastic LB and it is not using sticky sessions; requests are round robin. I implemented session replication using spring-session with gemfire for session storage. This works well.
I need to integrate with an OAuth2 auth server (and eventually multiple OAuth2 servers) purely for authentication and the passing of userInfo. I attempted to use the spring cloud oauth2 #EnableOAuth2Sso on the web-app and hit some session serialization issues. The mere addition of the oauth2ClientContext to the session seemed to cause ClassCastException problems during session saving.
I attempted to pull down the following samples and they worked well out of the box, Particularly the UI and the Authserver.
https://github.com/spring-guides/tut-spring-security-and-angular-js
However, when I added spring session into the mix, trying to serialize to a gemfire server, I encountered the exact same issue.
Here is the stacktrace highlight:
java.lang.ClassCastException: cannot assign instance of org.springframework.beans.factory.support.StaticListableBeanFactory to field org.springframework.aop.scope.DefaultScopedObject.beanFactory of type org.springframework.beans.factory.config.ConfigurableBeanFactory in instance of org.springframework.aop.scope.DefaultScopedObject
Below is abbreviated stacktrace:
ERROR o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception
org.springframework.dao.DataAccessResourceFailureException: remote server on machine(gemfire:21800:loner):57660:9d1f3438:gemfire: : While performing a remote put; nested exception is com.gemstone.gemfire.cache.client.ServerOperationException: remote server on machine(gemfire:21800:loner):57660:9d1f3438:gemfire: : While performing a remote put
at org.springframework.data.gemfire.GemfireCacheUtils.convertGemfireAccessException(GemfireCacheUtils.java:238) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
at org.springframework.data.gemfire.GemfireAccessor.convertGemFireAccessException(GemfireAccessor.java:91) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
at org.springframework.data.gemfire.GemfireTemplate.put(GemfireTemplate.java:190) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
at org.springframework.session.data.gemfire.GemFireOperationsSessionRepository.save(GemFireOperationsSessionRepository.java:147) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.data.gemfire.GemFireOperationsSessionRepository.save(GemFireOperationsSessionRepository.java:35) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.commitSession(SessionRepositoryFilter.java:244) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.SessionRepositoryFilter$SessionRepositoryRequestWrapper.access$100(SessionRepositoryFilter.java:214) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.SessionRepositoryFilter.doFilterInternal(SessionRepositoryFilter.java:167) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:80) ~[spring-session-1.2.1.RELEASE.jar:na]
... tomcat filter chain and spring filter stuff
Caused by: com.gemstone.gemfire.cache.client.ServerOperationException: remote server on machine(gemfire:21800:loner):57660:9d1f3438:gemfire: : While performing a remote put
... gemfire internal stuff
at org.springframework.data.gemfire.GemfireTemplate.put(GemfireTemplate.java:187) ~[spring-data-gemfire-1.7.4.RELEASE.jar:1.7.4.RELEASE]
... 31 common frames omitted
Caused by: java.lang.ClassCastException: cannot assign instance of org.springframework.beans.factory.support.StaticListableBeanFactory to field org.springframework.aop.scope.DefaultScopedObject.beanFactory of type org.springframework.beans.factory.config.ConfigurableBeanFactory in instance of org.springframework.aop.scope.DefaultScopedObject
at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2133) ~[na:1.7.0_80]
at java.io.ObjectStreamClass.setObjFieldValues(ObjectStreamClass.java:1305) ~[na:1.7.0_80]
... java.io stuff
at org.springframework.aop.framework.AdvisedSupport.readObject(AdvisedSupport.java:557) ~[spring-aop-4.3.2.RELEASE.jar:4.3.2.RELEASE]
at sun.reflect.GeneratedMethodAccessor224.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_80]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.7.0_80]
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058) ~[na:1.7.0_80]
... java.io stuff
at com.gemstone.gemfire.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2966) ~[gemfire-8.1.0.jar:na]
at com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3210) ~[gemfire-8.1.0.jar:na]
at org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSessionAttributes.readObject(AbstractGemFireOperationsSessionRepository.java:800) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSessionAttributes.fromDelta(AbstractGemFireOperationsSessionRepository.java:834) ~[spring-session-1.2.1.RELEASE.jar:na]
at org.springframework.session.data.gemfire.AbstractGemFireOperationsSessionRepository$GemFireSession.fromDelta(AbstractGemFireOperationsSessionRepository.java:589) ~[spring-session-1.2.1.RELEASE.jar:na]
at com.gemstone.gemfire.internal.cache.EntryEventImpl.processDeltaBytes(EntryEventImpl.java:1345) ~[gemfire-8.1.0.jar:na]
... gemfire internal stuff
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.7.0_80]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.7.0_80]
at com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:577) ~[gemfire-8.1.0.jar:na]
... 1 common frames omitted
I found the following, https://jira.spring.io/browse/SPR-14117, which encouraged me to update some of the jars to the newest versions, hoping the spring boot versions were simply behind, however it didn't seem to help.
Version info:
spring-cloud-starter-parent: Brixton.SR4
spring-cloud-security: 1.1.2.RELEASE
spring-core: 4.3.2.RELEASE
spring-security-oauth2: 2.0.10.RELEASE
spring-session: 1.2.1.RELEASE
I've considered a few options: rewiring the OAuth2 framework to no longer use ScopedProxyMode.INTERFACES (seems daunting), use Redis vs. Gemfire, write the entire client from scratch (I've done it before... wasn't fun).
FWIW I've already added the RequestContextFilter as recommended here: OAuth2ClientContext (spring-security-oauth2) not persisted in Redis when using spring-session and spring-cloud-security
Does anyone have any guidance?
I don't know if this speaks to your problem directly but I had/have a similar problem and I think I have all the same versions as you. Seems that there are so many Spring projects and they all try to keep up with each other so sometimes there seem to be compatibility issues. I found the steps outlined here by Rob Winch fixed my issue -https://github.com/spring-projects/spring-session/issues/395
I am unable to get MyEclipse to connect to the marketplace. I am aware of the proxy setup. These are the steps I followed within a proxy environment and within a direct environment.
A. Within the Company Network. (browers use automatic configuration script)
Chose Native option. Does not work.
Chose Manual option. Set the domain, username. Opened the proxy script to figure out available proxy servers. Verified independently that these proxy servers work. Does not work.
Modified the vmargs to provide the http host, user, password and port properties. Does not work.
Did steps 1-3 with restarts of Eclipse.
B. Within home environment. (Direct connection to internet)
Tried Direct Option. Does not work.
Tried Native Option. Does not work.
The error message that I constantly see (through error logs) is this.
java.lang.reflect.InvocationTargetException
at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$3.run(MarketplaceWizardCommand.java:203)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Caused by: org.eclipse.core.runtime.CoreException: HTTP Server Unknown HTTP Response Code (-1):http://marketplace.eclipse.org/catalogs/api/p
at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:161)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.epp.internal.mpc.core.util.AbstractP2TransportFactory.invokeStream(AbstractP2TransportFactory.java:35)
at org.eclipse.epp.internal.mpc.core.util.TransportFactory$1.stream(TransportFactory.java:69)
at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:141)
at org.eclipse.epp.internal.mpc.core.service.RemoteMarketplaceService.processRequest(RemoteMarketplaceService.java:80)
at org.eclipse.epp.internal.mpc.core.service.DefaultCatalogService.listCatalogs(DefaultCatalogService.java:36)
at org.eclipse.epp.internal.mpc.ui.commands.MarketplaceWizardCommand$3.run(MarketplaceWizardCommand.java:200)
... 1 more
Caused by: org.eclipse.ecf.filetransfer.BrowseFileTransferException: Could not connect to http://marketplace.eclipse.org/catalogs/api/p
at com.genuitec.pulse2.common.http.ecf.PulseRetrieveFileTransfer.openStreams(Unknown Source)
at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:889)
at org.eclipse.ecf.provider.filetransfer.retrieve.AbstractRetrieveFileTransfer.sendRetrieveRequest(AbstractRetrieveFileTransfer.java:576)
at org.eclipse.ecf.provider.filetransfer.retrieve.MultiProtocolRetrieveAdapter.sendRetrieveRequest(MultiProtocolRetrieveAdapter.java:106)
at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileReader.java:349)
at org.eclipse.equinox.internal.p2.transport.ecf.FileReader.read(FileReader.java:213)
at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:153)
... 11 more
Is there any alternative or any other step that I can take to resolve this problem. I know I can go through the manual update by downloading the plugin and all. But I really want to solve this issue.
MyEclipse Version Information:
MyEclipse Blue Edition
Version: 10.7.1 Blue
Build id: 10.7.1-Blue-20130201
Apparently it could be a bug.
I just read this whole bug report here.
I tried adding the VM arguments to ensure the the HTTPClient workaround can be achieved via a configuration change. Did not work.
However, I was able to remove the http client libraries from the plugins folder, courtesy Comment #27 and #29 on the bug report.
Now I'm able to connect over proxy and direct as well.
I'm using JMeter with a load of 3-6 users. And I often get the exception below. Please, tell me what is the cause of this problem? Is this a trouble with JMeter or with server's application? thank you in advance.
Exception is next:
java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:481)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:298)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1105)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1094)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:429)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:257)
at java.lang.Thread.run(Unknown Source)
Okay i had this problem and the solution i tried and worked was to update Java version. From 1.8 to 1.12.
As it is a Jar (a Java program compiled) if you try to run it with a previous version of java it might result in this error.
This works for me:
Search "Update Java" on your computer menu and select it, after, on the Java Control Panel, select the option "Update". Now, select "Update Now". Wait for the installation and don't forget to select "Ok" to the end.
When Java is update, the POST works on JMeter. This is the same solution of AndiFB's answer.
Connection Reset since JMeter 2.10 ?
If you upgraded recently to JMeter 2.10 or 2.11, you may have noticed increased errors of this type:
Socket closed
Non HTTP response code: org.apache.http.NoHttpResponseException (the target server failed to respond)
Explanation
The increase of this type of errors can be explained by two settings changes:
retry of failing request (idempotent ones only) has been disabled in JMeter 2.10
stale check in HTTP Client 3 and 4 implementations has been disabled in JMeter 2.11
Why these changes?
Previous retry default settings led to increased number of Requests in certain type of failures.
Previous stale check was a bit expensive, as it applied to every sample. That is why the default was changed to disable it.
Retry or stale check can hide issues on Server configuration:
Server failing to send the (optional) Keep-Alive header
Overwhelmed server refusing connection, retrying would increase load
Changing configuration:
If you think this server behavior is OK, then configuration can be changed in two places:
Enabling retry
For HttpClient 4, in user.properties set :
httpclient4.retrycount=1
This will make JMeter retry once. For HttpClient 3, in user.properties set:
httpclient3.retrycount=1
This will make JMeter retry once.
Enabling stale check
For HC4 Implementation:
In user.properties:
hc.parameters.file=hc.parameters
In hc.parameters set:
http.connection.stalecheck$Boolean=true
For HC3 Implementation:
In user.properties:
httpclient.parameters.file=httpclient.parameters
In httpclient.parameters set:
http.connection.stalecheck$Boolean=true
New setting in JMeter 2.12
Upcoming version of JMeter adds a setting to add an idle connection timeout if the server does not send Keep-Alive headers.
This value is in milliseconds:
httpclient4.idletimeout=