Access static file cause "Connection reset by peer" exception - vert.x

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.

Related

Failed to read challenge file [Caused by java.io.FileNotFoundException: /jboss/standalone/tmp/auth/local4123__.challenge (No such file or directory)

I am trying to connect two machines both running JBoss EAP 7.1.0 using a JMS bridge. Machine 1 is to act as a web server and has a WAR file deployed which is accessible, and Machine 2 is to act as the app server and has all the necessary components deployed just fine.
This is the error I am receiving:
WARN [org.apache.activemq.artemis.jms.bridge] (ServerService Thread Pool -- 72) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: javax.security.sasl.SaslException: ELY05128: [JBOSS-LOCAL-USER] Failed to read challenge file [Caused by java.io.FileNotFoundException: /.../.../jboss/standalone/tmp/auth/local3093626581916142639.challenge (No such file or directory)]]
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:53)
at org.wildfly.naming.client.NamingProvider.getPeerIdentityForNamingUsingRetry(NamingProvider.java:105)
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNamingUsingRetry(RemoteNamingProvider.java:91)
at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:189)
at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:222)
at org.wildfly.naming.client.remote.RemoteContext.performWithRetry(RemoteContext.java:100)
at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:188)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:74)
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:60)
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.start(JMSBridgeImpl.java:398)
at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService.startBridge(JMSBridgeService.java:114)
at org.wildfly.extension.messaging.activemq.jms.bridge.JMSBridgeService$1.run(JMSBridgeService.java:84)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
The connection to the target machine (application server) is being made as the path to JBoss is that of the path on the machine, which I verified by testing with a Windows application server environment and the path was the correct Windows path to the directory where the challenge file should be, so clearly the connection is being made as the directories are being accessed. However, the .challenge file isn't present each time which understandably causes the error message.
I have scoured SO and JBoss forums for days now and nothing is resolving my issue.
I saw this post: JBOSS-LOCAL-USER: javax.security.sasl.SaslException: Failed to read server challenge
This is the same issue that I am facing, but the answer which was marked as correct doesn't help me very much. The solution, in this case, was to replace the default ApplicationRealm with a JAAS realm, but I do not know if this is what I need, and I certainly do not currently have one. I did research it, but it seemed to not be applicable to my setup, but I could be wrong.
I also tried this solution: https://access.redhat.com/solutions/3209281 (Subscription only access)
This solution was to remove default-user="$local" from here:
<security-realm name="ApplicationRealm">
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
I did this to both standalone-full.xml files on both machines, and it appeared to make no difference at all.
I have created application users on both machines and given them superuser privileges through the JBoss console as I figured it was probably an issue with permissions when trying to write the file but this too was to no avail. I have also verified that both user credentials are correct.
The workaround was to switch to using a core bridge instead of a JMS bridge, as per the recommendation from Justin in the comments.

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?

Error Connecting To Remote Host In Mirth

I need to create a connection between a lab machine and a server.
The lab machine can send HL7 messages for test results.
I decided to use mirthconnect to process the message and so i created a channel.
The channel source connector was configured as a "TCP LISTENER"
The Listener settings use a "specific interface" with ip address of the machine entered.
Response settings are configured to "auto-generate after source transformer"
Transmission mode is "MLLP" using "Server" mode.
Receive timeout is 0 ms, and "keep Connection Open" radio button is checked.
I also specified a port number "2468" to listen on and it showed as enabled when i did a
"netstat -at" command.
On the sending computer on the network, i created a channel again and i put in the IP address of the first machine with the receiving channel on the destination. I also put in the port number that was used when creating the channel on the "receiving" computer.
However when i clicked on the "Test Connection" button i got an
unable to connect to host error
I also tried to send a message after deploying the channel and the message was not sent.
The error generated is shown below:
TCP Sender error
ERROR MESSAGE: Connection refused: connect
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at com.mirth.connect.connectors.tcp.SocketUtil.connectSocket(SocketUtil.java:62)
at com.mirth.connect.connectors.tcp.TcpDispatcher.send(TcpDispatcher.java:213)
at com.mirth.connect.donkey.server.channel.DestinationConnector.handleSend(DestinationConnector.java:599)
at com.mirth.connect.donkey.server.channel.DestinationConnector.process(DestinationConnector.java:336)
at com.mirth.connect.donkey.server.channel.DestinationChain.call(DestinationChain.java:224)
at com.mirth.connect.donkey.server.channel.Channel.process(Channel.java:1428)
at com.mirth.connect.donkey.server.channel.Channel.dispatchRawMessage(Channel.java:956)
at com.mirth.connect.donkey.server.channel.SourceConnector.dispatchRawMessage(SourceConnector.java:175)
at com.mirth.connect.server.controllers.DonkeyEngineController.dispatchRawMessage(DonkeyEngineController.java:520)
at com.mirth.connect.server.servlets.MessageObjectServlet$2.run(MessageObjectServlet.java:193)
at java.lang.Thread.run(Unknown Source)
I can successfully ping both systems and can connect to a MySQL server on the host by using
mysql -utest -ptest -hipaddressofhost
I am using Mirthconnect 3.0.
Please where am i missing it?...thanks
(I also have not encrypted the message nor am i using SSL To test the transmission...i believe this is not an issue??)
There is several things that could possibly go wrong with something that seems as simple as this is:
Did you verify that you have no firewall installed or active. The commands you use seem to indicate that you may be using Linux. As such, you could become quite frustrated by something like iptables (/etc/init.d/iptables status) or another firewall like that.
Are you sure you do not have any kind of firewall in the way that would prevent network communications between the sender and the box that is listening on port 2468? Are they on the same subnets? If they are not on the same subnet it is possible that some kind of network device/firewall is blocking the traffic.
Can you telnet to the listener's ip address and port (telnet )?
Another simple way to test if you are on the right path is to import the channel (or just the destination that is sending to the listener) into the listener machine's Mirth instance. If you are able to establish a connection while not making any changes to the port and ip address in this destination you probably have some kind of network/firewall issue that is preventing traffic on that specific port from getting through.
Not sure if this will help you much, but good luck either way.
Frans

How do I connect the NetBeans profiler to a specic remote instance

I have a remote GlassFish server that has a node agent configured. The instance I want to start in profiling mode is controlled by the node agent.
I've installed and calibrated the remote pack and I've modified my domain.xml for the specific instance as follows:
<profiler enabled="true" name="NetBeansProfiler">
<jvm-options>-agentpath:/home/glassfish/glassfish/profiler-server-6.0rc1-linux/lib/deployed/jdk16/linux/libprofilerinterface.so=/home/glassfish/glassfish/profiler-server-6.0rc1-linux/lib,5140</jvm-options>
</profiler>
Now at this point NetBeans tells you to start the domain with the --verbose command but in my case I'm trying to start an instance and "asadmin start-instance" doesn't support --verbose. I've checked the server.log but I'm not seeing any error nor any language that says it's waiting when I try to start the instances.
However, I think GlassFish is properly configured and my NetBeans setup is the issue. Where I think the issue might be is trying to specify the port. If I leave the port off, it just tries to connect forever. If I put the port on it just closes the dialog and the status shows "Inactive".
UPDATE:
It seems there might be a bug with GF2. After verifying everything and getting the server so that it was listening, the following exception is thrown
Could not load Logmanager "com.sun.enterprise.server.logging.ServerLogManager"
java.lang.ClassNotFoundException: com.sun.enterprise.server.logging.ServerLogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.util.logging.LogManager$1.run(LogManager.java:166)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.(LogManager.java:156)
According to this URL, http://java.net/jira/browse/GLASSFISH-3256 it's a known issue and won't be fixed until GF3.
Anyway, my question was about how to connect to a specific instance and I think that was answered.
Do not include the port number in the hostname field. The port number is taken from the global profiler settings.