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:

Comments:

Hey,

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.

Gerard

Posted by gerard davison on November 06, 2013 at 03:49 PM CET #

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.

Thanks,
Pavel

Posted by Pavel on November 07, 2013 at 11:00 AM CET #

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..

Posted by Pavel on November 07, 2013 at 11:21 AM CET #

Ah,

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

Gerard

Posted by gerard davison on November 07, 2013 at 02:10 PM CET #

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..

Posted by Pavel on November 07, 2013 at 02:16 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Pavel Bucek

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today