Akka Http Error: InvalidContentLengthException - scala

We have an Akka HTTP Server serving some scala JS content on AWS. We've noticed that after some time, the server starts throwing the error below in the logs and although, the certain URL's work, but some files fail to be downloaded correctly with the Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH error in the browser. The server logs looks like below (it's exactly the same error in all instances):
[ERROR] [09/29/2016 21:29:22.150] [designer-actor-system-akka.actor.default-dispatcher-56831] [akka.actor.ActorSystemImpl(designer-actor-system)] Outgoing response stream error
akka.http.scaladsl.model.InvalidContentLengthException: HTTP message had declared Content-Length 997 but entity data stream amounts to 164 bytes less
at akka.http.scaladsl.model.InvalidContentLengthException$.apply(ErrorInfo.scala:50)
at akka.http.impl.engine.rendering.RenderSupport$CheckContentLengthTransformer$$anon$2.onUpstreamFinish(RenderSupport.scala:130)
at akka.stream.impl.fusing.GraphInterpreter.processEvent(GraphInterpreter.scala:732)
at akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:616)
at akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:471)
at akka.stream.impl.fusing.GraphInterpreterShell.receive(ActorGraphInterpreter.scala:433)
at akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:603)
at akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:618)
at akka.actor.Actor$class.aroundReceive(Actor.scala:484)
at akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:529)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
at akka.actor.ActorCell.invoke(ActorCell.scala:495)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
at akka.dispatch.Mailbox.run(Mailbox.scala:224)
at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
We are running Akka version 2.4.7 and OpenJDK version 1.8.0_101-b13.The error goes away if we restart the Akka HTTP server, but comes back again after a few hours.
Not sure what is causing the issue. Any help would be greatly appreciated.

I think I figured out what was causing it. We had an automated deployment process that deploys HTML/CSS/Javascript files to the Akka server. It seems like the Akka server caches content size and if the static files are updated without restarting, it would give InvalidContentLengthException. We included the restart as part of deployment process and the problem seems to have been resolved.

Related

JBoss automatic .war redeployment can't start application properly - Error on Keycloak redirection

A colleague of mine wants to automate their JBoss (JBoss EAP v7.4.0) deployments.
So far the process they followed manually was:
Shutdown Jboss entirely
Copy the new .war file under /jboss-eap-7.4.0/standalone/deployments directory
Restart the server by executing standalone.sh
This process, although a bit 'dump', manages to deploy the application with no issues.
I on the other hand, tried to make use of JBoss's auto-redeployment feature, so I simply pasted the new .war file under the /jboss-eap-7.4.0/standalone/deployments directory.
JBoss indeed picks up the new .war and automatically starts the redeployment process.
From the server.log file, it seems at first that the application deploys successfully.
However when I try to access it from my browser, it crashes and gives a code 500 response (See error logs at the end of the post). The expected behavior would be to redeploy me to keycloak in order to login.
The exact same error occurs if I try to manually undeploy and deploy the .war from the jboss.cli.
Any hints on the issue?
I can't figure out if the error is on the server or the application side.
It seems a bit odd that it should require a full JBoss server restart in order for the application to be properly deployed.
Thank you in advance.
Server logs:
2022-06-14 17:22:25,850 WARN [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) The input bytes to the digest operation are null. This may be due to a problem with the Reference URI or its Transforms.
2022-06-14 17:22:25,879 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /myapplication: java.lang.RuntimeException: Could not create authentication request.
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:64)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.ElytronHttpFacade.noAuthenticationInProgress(ElytronHttpFacade.java:123)
at org.keycloak.keycloak-saml-wildfly-elytron-adapter#15.0.2//org.keycloak.adapters.saml.elytron.KeycloakHttpServerAuthenticationMechanism.evaluateRequest(KeycloakHttpServerAuthenticationMechanism.java:125)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:119)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.util.SocketAddressCallbackServerMechanismFactory$1.evaluateRequest(SocketAddressCallbackServerMechanismFactory.java:82)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:85)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:326)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$800(HttpAuthenticator.java:301)
at org.wildfly.security.elytron-private#1.15.3.Final-redhat-00001//org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:94)
at org.wildfly.security.elytron-web.undertow-server#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl.authenticate(ServletSecurityContextImpl.java:115)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at org.wildfly.security.elytron-web.undertow-server-servlet#1.9.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at org.wildfly.extension.undertow#7.4.0.GA-redhat-00005//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet#2.2.5.Final-redhat-00001//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
at io.undertow.core#2.2.5.Final-redhat-00001//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.4.0.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at org.jboss.xnio#3.8.4.Final-redhat-00001//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.apache.xml.serializer.utils.WrappedRuntimeException: class org.apache.xml.serializer.ToXMLSAXHandler cannot be cast to class org.apache.xml.serializer.SerializationHandler (org.apache.xml.serializer.ToXMLSAXHandler is in unnamed module of loader 'deployment.myapplication.war' #15a25903; org.apache.xml.serializer.SerializationHandler is in unnamed module of loader 'deployment.myapplication.war' #68ae4310)
at deployment.myapplication.war//org.apache.xml.serializer.SerializerFactory.getSerializer(SerializerFactory.java:179)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.createResultContentHandler(TransformerIdentityImpl.java:261)
at deployment.myapplication.war//org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:330)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getNodeAsString(DocumentUtil.java:228)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.common.util.DocumentUtil.getDocumentAsString(DocumentUtil.java:207)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.getSAMLResponse(BaseSAML2BindingBuilder.java:311)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder.buildHtmlPostResponse(BaseSAML2BindingBuilder.java:307)
at org.keycloak.keycloak-saml-core#15.0.2//org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.getHtmlRequest(BaseSAML2BindingBuilder.java:172)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.SamlUtil.sendSaml(SamlUtil.java:45)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.profile.AbstractSamlAuthenticationHandler$3.sendAuthnRequest(AbstractSamlAuthenticationHandler.java:622)
at org.keycloak.keycloak-saml-adapter-core#15.0.2//org.keycloak.adapters.saml.AbstractInitiateLogin.challenge(AbstractInitiateLogin.java:61)

Access static file cause "Connection reset by peer" exception

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.

SymmetricDS encounters illegalStateException

Setup
SymmetricDS version is 3.9.1 (also tried 3.9.0)
Setup is from postgres 9.5.3 to postgres 9.5.3
Windows 10 pc (client node) to windows server 2012 (master node).
The client is my work pc (local) and the windows server is on the other side of the country. The registration url for the client and sync url for the master node are using a dns resolver to get the ip of the server.
The client connects to the server successfully though registration and creates the appropriate triggers on the client. This error occurs while trying to sync.
Getting this message on the client:
PushService - We expected but did not receive an ack for batch liveServer-2.
PushService - This could be because the batch is corrupt. Removing the batch
from staging
The response on the server is:
DataLoaderService - Failed while parsing batch
java.lang.IllegalStateException: Invalid batch data was received: ▼∩┐
∩┐╜TK∩┐╜∩┐╜6►∩┐╜∩┐╜j∩┐╜∩┐╜¶g∩┐╜c∩┐╜☼▲∩┐╜-2x↕
R♀∩┐╜ S∩┐╜∩┐╜J∩┐╜♣xbK∩┐╜$&C~}Z~∩┐╜♀∩┐╜nr∩┐╜!Pr∩┐╜∩┐╜∩┐╜∩┐╜jY∩┐╜Z╚é∩┐╜♣
at org.jumpmind.symmetric.io.stage.SimpleStagingDataWriter.process(SimpleStagingDataWriter.java:194)
at org.jumpmind.symmetric.service.impl.DataLoaderService.loadDataFromTransport(DataLoaderService.java:568)
at org.jumpmind.symmetric.service.impl.DataLoaderService.loadDataFromPush(DataLoaderService.java:398)
at org.jumpmind.symmetric.web.PushUriHandler.push(PushUriHandler.java:83)
at org.jumpmind.symmetric.web.PushUriHandler.handle(PushUriHandler.java:68)
at org.jumpmind.symmetric.web.SymmetricServlet.service(SymmetricServlet.java:114)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:833)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at org.jumpmind.symmetric.web.HttpMethodFilter.doFilter(HttpMethodFilter.java:62)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:561)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:334)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:104)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:243)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:679)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:597)
at java.lang.Thread.run(Unknown Source)
How can I resolve this? What could I have done wrong?
I used the same setup between a windows 10 pc (client node) to a Windows 2012 Virtual machine (master node) on the same network and it works fine. This error only seems to occur when I try to connect to a remote server with my pc as the client.
Seeing those odd characters makes me think it was an encoding issue so I tried adding the option to the end of the db.url and also the #db.read.strings.as.bytes=true tag in the engine files
I also tried re-importing the client database from a previous backup encase it was corrupted. Same result on the older version of the database.
If I had to guess perhaps something along the route is encrypting or garbling the packets leading to bad data.
One thing that might be happening is a network device in between your nodes is stripping or modifying HTTP headers. SymmetricDS gzips the data when it goes over the wire and sets the HTTP header Content-Encoding: gzip. If the content-encoding header is not set to gzip when it reaches the other side, you would get junk output like you are seeing.

java.net.SocketException: Socket closed, JMeter

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=

IllegalStateException: Committed ; Committed before 500 org.eclipse.jetty.io.EofException

I am getting this below error when I checked the jetty logs.
From the posts on ther sites, it seems that the solaris response was too slow for the client and it's trying to send a response back to someone
who's no longer listening for one.
Please let me know if anybody has any idea regarding this. Thanks in advance.
2014-08-01 10:10:08.377:WARN:oejs.Response:qtp136272369-10006: Committed before 500 org.eclipse.jetty.io.EofException
2014-08-01 10:10:08.378:WARN:oejs.ServletHandler:qtp136272369-10006: /estore-web/dec/ret/admin/session/getSessionObject/16019
java.lang.IllegalStateException: Committed
at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1004)
at org.eclipse.jetty.server.Response.sendError(Response.java:353)
at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:71)
at org.jboss.resteasy.core.SynchronousDispatcher.handleFailure(SynchronousDispatcher.java:262)
at org.jboss.resteasy.core.SynchronousDispatcher.handleWriterException(SynchronousDispatcher.java:379)
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:218)
at org.jboss.resteasy.core.SynchronousDispatcher.handleWriteResponseException(SynchronousDispatcher.java:203)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:504)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:696)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1515)
at com.tme.user.management.security.filter.BearerTokenAuthenticatingFilter.doFilter(BearerTokenAuthenticatingFilter.java:151)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1495)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:519)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1097)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:448)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1031)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:200)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:446)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:271)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:246)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
at java.lang.Thread.run(Thread.java:745)
Theoretically, it says: An existing connection was forcibly closed by the remote host Some reasons:
Bad network connection
Host shutdown
Time-outs
Bottle-neck with data overload
Intranet: Changed ip without changing intranet DNS
I am having the same exception. What were you trying to do when was it thrown?