Pavel Bucek's Weblog

  • November 4, 2013

Asynchronous connectToServer

Users of JSR-356 – Java API for WebSocket are probably familiar with WebSocketContainer#connectToServer method. This article will be about its usage and improvement which was introduce in recent Tyrus release.

WebSocketContainer#connectToServer does what is says, it connects to WebSocketServerEndpoint deployed on some compliant container. It has two or three parameters (depends on which representation of client endpoint are you providing) and returns aSession. Returned Session represents WebSocket connection and you are instantly able to send messages, register MessageHandlers, etc.

An issue might appear when you are trying to create responsive user interface and use this method – its execution blocks until Session is created which usually means some container needs to be started, DNS queried, connection created (it’s even more complicated when there is some proxy on the way), etc., so nothing which might be really considered as responsive. Trivial and correct solution is to do this in another thread and monitor the result, but.. why should users do that? :-) Tyrus now provides async* versions of all connectToServer methods, which performs only simple (=fast) check in the same thread and then fires a new one and performs all other tasks there. Return type of these methods is Future<Session>.

List of added methods:

As you can see, all connectToServer variants have its async* alternative. All these methods do throw DeploymentException, same as synchronous variants, but some of these errors cannot be thrown as a result of the first method call, so you might get it as the cause ofExecutionException thrown when Future<Session>.get() is called.

Please let us know if you find these newly added methods useful or if you would like to change something (signature, functionality, …) – you can send us a comment to users@tyrus.java.net or ping me personally.

Related links:

Join the discussion

Comments ( 5 )
  • gerard davison Wednesday, November 6, 2013


    Remembering back to my JAX-WS days it would be useful in a lot of cases to have either a callback hander or something like CompletableFuture returned. (Obviously much smaller for users of < JDK 8)

    This prevents the client thread for having to be bothered with polling, of waiting on the connection.


  • Pavel Thursday, November 7, 2013

    Hi Gerard,

    good feedback, thanks! Can you please create RFE on Tyrus issue tracker (https://java.net/jira/browse/TYRUS)? If not, then I will do it by myself later.



  • Pavel Thursday, November 7, 2013

    Actually - second thought - you already have the callback you are referring to: @OnOpen annotated method will be called after client is connected and session is created, so .. introducing another one might seem redundant. I see why you could take an advantage of another one, just wanted to point out that the solution is already there..

  • gerard davison Thursday, November 7, 2013


    Yes you are right, no need for the extra API really.


  • Pavel Thursday, November 7, 2013

    third thought :)

    @OnOpen is perfectly usable for positive case - client is able to establish connection to server endpoint. But what if there is some issue? @OnError won't be called (this might be changed..), so parent process must call Future<Session>.get() to get the error. So seems like your original issue is still valid..

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.