Generally people compared Websockets and http long polling.
But in connection pooling using http 1.1 (which browser does or we do from application server to db server ) , persistent connection is made and all http requests made through same connection (similar concepts of Websockets)
Only difference is Websockets is bidirectional but http 1.1 connection will be request/response based.
Any other difference?
Related
Maybe somebody has experienced this and can help me out.
I have a Reactive WebSocket server (WebFlux Spring Boot).
I checked the connection to the server by Postman and all is good, the connection lasts a long time, but I don't know how long this connection will last with another clients, so I want to set a couple of parameters: InputBufferSize and Timeout, I found how can do it for some servers (Jetty, TomCat,..):
https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#websocket-server-runtime-configuration
But I cannot find how can do it for Netty (I use Reactive WebSocket, based on Netty).
How can set InputBufferSize and Timeout of connection for Netty (Reactive Spring)?
And another question is how to send ping-pong (heartbeats), I think I can do it in MyHandler (that implements org.springframework.web.reactive.socket.WebSocketHandler), in
#Override
public Mono handle(WebSocketSession session)
WebSocketMessage has field type (enum: TEXT, BINARY, PING, PONG) I can use it for ping-pong (heartbeats) between any client and my server part. But many forums write that the Netty has already implemented this process (ping-pong) and it will be superfluous - to add it manually in WebSocketHandler. I'm confused here, should I write additional processing (ping-pong in WebSocketHandler) or it will be an unnecessary layer on top of the already made part in Netty?
I have a simple web app, which is using websockets.
simple webapp:
Frontend - using sockjs, stomp
Backend - Spring 4.2.x
Frontend & Backend are packaged in the same WAR, this WAR is deployed on IBM WebSphere Application Server v9.x
When I check the Developer Tools/Web Console in chrome(61.x)/firefox(56.0, 32 bit), I see that websocket transport is not being used, it's always xhr streaming. To use the websocket transport, I have passed the transports option in sockjs, like below, but after this change the websockets stopped working.
var sockjs = new SockJS(my url, null, {transports: ["websocket"]});
Do we need to change any configuration on IBM WebSphere Application Server v9.x to enable websocket transport ?
Update: on tomcat/liberty servers, sample app always uses websocket transport. Only on WAS, it is using xhr streaming. Issue in WAS?
Websocket protocol handling is on by default for Websphere v9.x
I haven't found any solution about this. It seems Jetty doesn't support this feature yet. I might be wrong so please, enlighten me.
I've got a very simple Java client which connects to a Java server at localhost:8080. I would like to add a transparent proxy between them in order to simulate what we could find in a company's private network.
Update: May, 2017
Starting in Jetty 9.4.0 and onwards, the native Jetty WebSocketClient supports Proxies via the Jetty HttpClient.
This works by declaring an HttpClient, along with its proxy configurations, and then handing that off to the WebSocketClient constructor to use.
This only works with the following:
HTTP/1.1 upgrade to WebSocket
Native Jetty WebSocket APIs
This does not work with the following:
HTTP/2 (there is no spec for WebSocket over HTTP/2 as of yet)
JSR356 javax.websocket (there are ideas for API breaking changes to the JSR356 ClientContainer to allow passing in a Jetty HttpClient via a constructor, let us know if this is viable option for you by filing a new issue on github saying so)
Original Answer
With Jetty 9, there's no Proxy support for either the Jetty Native WebSocket client, or the JSR-356 (javax.websocket) client implementation.
This support is scheduled for Jetty 10 (which is tracking Servlet 4), and will result in a complete reworking of the entire client library suite in Jetty to have equal support for :
HTTP/1.1
HTTP/2 (native/direct)
HTTP/1.1 upgrade to HTTP/2 (h2c)
HTTP/1.1 upgrade to WebSocket
HTTP/2 websocket channel (currently in draft specs)
Proxy support
Cookie support
etc ...
The existing WebSocket client implementations on Jetty are standalone, due to the JSR-356 support requirements.
The existing WebSocket client does not leverage the existing Jetty HttpClient in Jetty 9.x. If it did then proxy support could, maybe, under a very limited set of scenarios, work.
This is a low priority feature request, as there are few existing proxies out there that support WebSocket so far (actually, they have generally bad support for HTTP/1.1 upgrade). Even Jetty's own Server side Proxy does not currently support HTTP/1.1 upgraded connections.
According to Figure 2 in How HTML5 Web Sockets Interact With Proxy Servers, if you are trying to use a transparent proxy, you don't have to require a proxy support on the client side. On the other hand, an explicit proxy requires client libraries to support proxy.
Jetty WebSocket client won't have any problem if your proxy is transparent.
From EJB transaction I am calling remote site using SOAP. Remote server is not responding. I got transaction time-out. But I want to get time-out from remote call.
How can I set time-out for SOAP request globally?
How can I set time-out for SOAP request for particular call?
You should be able to configure this using a Policy Set. See the link below for IBM's documentation on the topic.
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.doc%2Fae%2Frwbs_jaxwstimeouts.html
To globally set timeout, you may use HTTP transport custom properties for web services applications. The timeout you're looking for here is timeout. This is by default 300 seconds (which is more than global transaction timeout default value, which is 120 seconds, hence you receive a transaction time-out).
If you are using JAX-RPC, make sure you are at a patch level containing fix for PM60752 (6.1.0.45, 7.0.0.25, 8.0.0.5 and 8.5.0.1).
As indicated at Nick's answer, you have alternative methods to configure timeouts if you are using the newer JAX-WS stack.
When using JAX-RPC you may set timeout for a particular call endpoint as explained in article Setting the timeout value for a JAX-RPC Web Service client. For JAX-WS you may use bindings or go for one of the solutions at How to Set Timeout for JAX-WS WebService Call.
One thing to keep in mind when configuring timeouts for web services is that web service transport depends on HTTP transport (assuming SOAP over HTTP), and in turn that depends on TCP transport, all of which are configurable for various timeouts. The relations between these layers and solutions to common problems are outlined at Common Timeouts effecting Web Services, HTTP and SOAP clients article.
Hi there i am wondering if i create a webapp that uses Spring AMQP. Is that single webapp 1 AMQP client? Or is every request made by a user that results into an AMQP call a client, so potentially x numbers of clients?
I don't know AMQP much, but I suspect it has the same terminology as jms. In that sense your application is probably pooling connections to AMQP broker for better performance. Each connection in a pool is treated as a separate client (competing consumer).
Thus each request is not really creating a new connection (client), but your application isn't a single client as well. In fact, when your application tries to access AMQP broker, it picks any connection from the pool and puts it back once it's done. Another request can reuse the same connection (client) or use a different, idle one.