I am using activeMQ as a full featured broker. I have deployed my spring application on Tomcat 8.0.8. I am sending very large messages and I do it in separate Thread (about 230000 stomp messages in while loop). When I use Chrome, or Firefox in activeMQ console, I see that messages are being consumed almost instantly. The problem as always is IE. I can see that it stops to consume messages (after about 1000), and Tomcat fails at
java.lang.Thread.run(Thread.java:722) aused by: org.apache.catalina.connector.ClientAbortException: java.io.IOExcepti n: An existing connection was forcibly closed by the remote host at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffe .java:396) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java: 42) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:31 ) etc....
Is IE such slow a consumer by default or what? I have tried with numerous slow consumer politic with ActiveMQ but without success.
The exception points to an IO error of some sort on the client side. You can try to track what happens on the client side, e.g. use Fiddler to check for any reported errors, or if that fails Wireshark to track what HTTP messages are sent out and how far it gets. Also try using the latest 4.0.6.BUILD-SNAPSHOT (or better yet 4.1.0.BUILD-SNAPSHOT) available from repo.spring.io/libs-snapshot. There are some recent SockJS related fixes worth trying out.
I have tried with 4.1.0.BUILD-SNAPSHOT, but with no success. After a while Fiddler reports:
POST mylink/ami-0.1.0/liveEvents/072/omseen4z/xhr_send?t=1404832405318 HTTP/1.1
Accept: /
Accept-Language: en-us
Referer: mylink/ami-0.1.0/liveEvents/iframe.html#ensha4ej
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Host: mylink
Content-Length: 6
DNT: 1
Connection: Keep-Alive
Pragma: no-cache
Cookie: JSESSIONID=4CC71475E3FF1377C79D77C349710237; theme=standard
["\n"]
and HTTP/1.1 404 Not Found error occurs.
What can be the reason of this(new line message). I have added activemq prefetchSize of 1 and I do ack on every received message.
Marko
Related
We are getting connection closed error from server and want to gracefully close connection on our client end, i want to set keep-alive timeout on our end, but is there a way i can know keep-alive value on server end ? ( any curl flag) so i can set my keep-alive value lower than server value.
This is a SpringBoot website. When I debug it in Chrome, I find that there is Keep-Alive: timeout=38 in the response header.
I guess it means the max idle time a TCP connection can hold. This is from here
timeout: indicating the minimum amount of time an idle connection has to be kept opened (in seconds). Note that timeouts longer than the TCP timeout may be ignored if no keep-alive TCP message is set at the transport level.
Question 1: How to change the default value in SpringBoot? I update the appllicaiton.property and set server.connection-timeout=1200000000, no affect.
Question 2: If the browser side does not contain "Proxy-Connection: keep-alive" in the header, which means that it will not reuse the TCP connection. Now, if a TCP connection works for more than 38s because the content is too much to transfer from the browser to server, will it be closed by the server?
Edit: This morning when I debug Chrome for the same website, the keep-alive in response header is gone. That is werid. Why is it not there all the time?
I'm unable to get my application utilizing web sockets to work.
I have a site www.example.com which uses an anti-DDoS service so it resolves to IP X.X.X.X. The real address of the server is Y.Y.Y.Y. The anti-DDoS service does not proxy web sockets traffic so I wanted to stream it directly to the real address (it's difficult to find it for attack in reality so this will work) so what I did is instead of pointing it to ws://www.example.com:100/, I pointed it to ws://Y.Y.Y.Y:100/.
Now if I access my application by the real IP (http://Y.Y.Y.Y), it connects to ws://Y.Y.Y.Y:100/ just fine but if I use http://www.example.com link (which resolves to X.X.X.X), ws://Y.Y.Y.Y:100/ won't connect saying "WebSocket connection to 'ws://Y.Y.Y.Y:100/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED".
I guess this has something to do with security but I don't know what exactly. Please help.
Maybe the websocket server sees the domain in Origin HTTP header different than the domain in the Host HTTP header and it is refusing the connection because of that. The Origin header is usually used to figure out if the connection is coming from an allowed website, since websockets are not under the Same Origin Policy.
The request that works will look like this:
GET / HTTP/1.1
Host: YYYY
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13
Origin: http://YYYY
The request that is refused will look like this:
GET / HTTP/1.1
Host: YYYY
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Version: 13
Origin: http://www.example.com
It is hard to tell with this little information. Don't you get any error in the server logs?
I am running squid 3.1 on CentOS 6.6. Sometimes when a machine enters into the network it starts causing forwarding loops in squid and as a result it slows down the internet. Something like this keeps filling cache.log
2015/07/20 10:58:44| WARNING: Forwarding loop detected for:
GET / HTTP/1.1
Host: 10.0.5.50:3128
Via: 1.0 squid.mydominname.com (squid/3.1.10), 1.1 squid.mydominname.com (squid/3.1.10)
X-Forwarded-For: 10.0.5.143, 10.0.5.50
Cache-Control: max-age=259200
Connection: keep-alive
After sometime I also get file descriptor error like so;
client_side.cc(2994) okToAccept: WARNING! Your cache is running out of
filedescriptors
X-Forwarded-For identifies the vulnerable machine. It happened in past that vulnerable machine contains suspicious software that caused this problem.
This doesn't happen all time but only when any bad machine enters into the network. Is there any squid configuration to prevent the network from that kind of forwarding loops?
I wrote a websocket server in c++ that works fine with websocket protocol 00 (the one with key1, key2 in handshake header).
Now with the new update I am trying to do the same for the new way handshaking work. Here is my server response to the handshake request:
"HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\nSec-WebSocket-Accept: " + serverKey + "\r\n\r\n";
in which serverkey is computed correctly. As an example:
handshake request:
GET /test HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 192.168.123.102:8585
Sec-WebSocket-Origin: http://192.168.123.5
Sec-WebSocket-Key: YB0mPvJ5t8ggCeGUWY39uQ==
Sec-WebSocket-Version: 8
handshake response header :
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: xt9iyCNryQTseELUkHPWjzxA2ts=
I also check my algo with the example here https://datatracker.ietf.org/doc/html/draft-ietf-hybi-thewebsocketprotocol-08 and it produced the exact same response.
However I still get the following error:
"Error during WebSocket handshake: Sec-WebSocket-Accept mismatch"
I am using chrome 15 as my browser.
Do you have any Idea what goes wrong?
(also in chrome inspector Network, it does not show the response which is the case when it does not accept the handshake (even with older versions))
I actually found out what was the primary problem.
the key that I used for base64 encoding was
YB0mPvJ5t8ggCeGUWY39uQ==
258EAFA5-E914-47DA-95CA-C5AB0DC85B11
instead of
YB0mPvJ5t8ggCeGUWY39uQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11
an extra \n was the whole problem.
HOWEVER, Now that I receive the Connected message (ws client is successfully connected to ws sever) I cannot send or receive anything. The problem is server side.
DO you know what are the server side changes since older websocket protocol? I only change my handshake respond and it doesnt seem enough.
There is a different framing protocol for when the client sends data. Previously it was quite simple. Now it is much more complicated. Please refer to the websockets rfc6455 spec.
https://www.rfc-editor.org/rfc/rfc6455#section-5.2