tyrus
  1. tyrus
  2. TYRUS-269

Parallel connection to ServerEndpoint with URI template mix up response to client instances ...

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.3.1, 1.4
    • Component/s: client, server
    • Labels:
      None
    • Environment:

      JDK 1.7.45 / Windows

      Description

      Making parallel connection to the "EchoEndpoint" with a Id as parameter in the URI.
      Responding in the @OnOpen the Id to the client.

      @ServerEndpoint("/multiecho/{ClientId}")
      public class EchoEndpoint {
      
      	private String clientId;
      
      	@OnOpen
      	public void onOpen(Session session, @PathParam("ClientId") String clientId) throws IOException {
      		this.clientId = clientId;
      		session.getBasicRemote().sendText("onOpen:" + clientId);
      	}
      
      	@OnMessage
      	public String echo(String message) {
      		return message + " (from your server to " + clientId + " )";
      	}
      
      }
      

      On client side executing multiple times the EndpointTester shows that the "clientId" get mixed up.

      	public class EndpointTester implements Callable<Boolean> {
      
      		@Override
      		public Boolean call() throws Exception {
      			MyEndpoint endpoint = new MyEndpoint(UUID.randomUUID().toString());
      			final ClientManager client = ClientManager.createClient();
      			Session session = client.connectToServer(endpoint, getURI("/multiecho/" + endpoint.clientId, null));
      
      			assertTrue("Connection not established!", endpoint.onOpenLatch.await(2, TimeUnit.SECONDS));
      			assertTrue("None or wrong message!", endpoint.messageLatch.await(2, TimeUnit.SECONDS));
      
      			return true;
      		}
      	}
      
      	@ClientEndpoint
      	public class MyEndpoint {
      
      		final String clientId;
      		final CountDownLatch messageLatch = new CountDownLatch(1);
      		final CountDownLatch onOpenLatch = new CountDownLatch(1);
      
      		public MyEndpoint(String clientId) {
      			this.clientId = clientId;
      		}
      
      		@OnOpen
      		public void opened(Session session) {
      			try {
      				session.getBasicRemote().sendText("Do or do not, there is no try.");
      			} catch (IOException ex) {
      				ex.printStackTrace();
      			}
      		}
      
      		@OnMessage
      		public void processMessage(String message, Session session) {
      			System.out.println(clientId + " ### Received: " + message);
      
      			if (message.startsWith("onOpen")) {
      				assertEquals("onOpen:" + clientId, message);
      				onOpenLatch.countDown();
      			} else {
      				assertEquals("Do or do not, there is no try. (from your server to " + clientId + " )", message);
      				messageLatch.countDown();
      			}
      
      		}
      	}
      
      

      IMHO the response should be received in the corresponding @ClientEndoint instance. But the Id's get mixed up.

        Activity

        Hide
        Pavel Bucek added a comment -

        reproduced on grizzly container

        I already have a "fix" - more like a workaround - synchonization of GrizzlyServerFilter#handleHandshake does fix described issue, but that should not be necessary. Still investigating..

        Show
        Pavel Bucek added a comment - reproduced on grizzly container I already have a "fix" - more like a workaround - synchonization of GrizzlyServerFilter#handleHandshake does fix described issue, but that should not be necessary. Still investigating..
        Hide
        Pavel Bucek added a comment -

        fix merged to the master branch.

        Show
        Pavel Bucek added a comment - fix merged to the master branch.

          People

          • Assignee:
            Pavel Bucek
            Reporter:
            helmut.at.work
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: