[TYRUS-429] Unexplainable WebSocket error Created: 09/Aug/16  Updated: 16/Aug/16

Status: Open
Project: tyrus
Component/s: server
Affects Version/s: 1.12, 1.13
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: soylomass Assignee: petrjanouch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RAM 8GB
Debian 7.5



 Description   

The server works perfectly fine, until at a random moment, it starts throwing hundreds of these per second:

Aug 09, 2016 10:54:08 AM org.glassfish.tyrus.container.grizzly.client.GrizzlyWriter$WriterCondition$1 onError
WARNING: Connection closed
java.io.IOException: Connection closed
at org.glassfish.grizzly.asyncqueue.TaskQueue.onClose(TaskQueue.java:331)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.onClose(AbstractNIOAsyncQueueWriter.java:501)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.closeConnection(TCPNIOTransport.java:402)
at org.glassfish.grizzly.nio.NIOConnection.doClose(NIOConnection.java:647)
at org.glassfish.grizzly.nio.NIOConnection$6.run(NIOConnection.java:613)
at org.glassfish.grizzly.nio.DefaultSelectorHandler$RunnableTask.run(DefaultSelectorHandler.java:495)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.processPendingTaskQueue(DefaultSelectorHandler.java:301)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.processPendingTasks(DefaultSelectorHandler.java:290)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.preSelect(DefaultSelectorHandler.java:101)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:335)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:279)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.read(TCPNIOTransport.java:597)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:75)
at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:526)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
... 3 more

The seconds previous were just normal:



 Comments   
Comment by soylomass [ 09/Aug/16 ]

I pressed submit by error, continue here:

The previous seconds were just normal:

ADD MASS 0.5
ADD XP 1.0
10:54:07
SERVER ID #0 COUNTS BOX 3000 TANKS 15 PERSONS 1 SOCKETS 21
OPEN SOCKETS 21ENDCOUNTS
ADD MASS 0.5
10:54:07
SERVER ID #1 COUNTS BOX 3000 TANKS 10 PERSONS 0 SOCKETS 12
OPEN SOCKETS 12ENDCOUNTS
ADD XP 1.0
ADD XP 1.0
REMOVE HEALTH
ADD XP 1.0
Close connection for client:

Unknown macro: {9de6dad0-36dc-4c4a-8a35-9aa7ac2cda7e}

ON CLOSE
ADD MASS 0.5
ADD XP 1.0
Aug 09, 2016 10:54:08 AM org.glassfish.tyrus.container.grizzly.client.GrizzlyWriter$WriterCondition$1 onError
WARNING: Connection closed
java.io.IOException: Connection closed
at org.glassfish.grizzly.asyncqueue.TaskQueue.onClose(TaskQueue.java:331)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.onClose(AbstractNIOAsyncQueueWriter.java:501)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.closeConnection(TCPNIOTransport.java:402)
at org.glassfish.grizzly.nio.NIOConnection.doClose(NIOConnection.java:647)
at org.glassfish.grizzly.nio.NIOConnection$6.run(NIOConnection.java:613)
at org.glassfish.grizzly.nio.DefaultSelectorHandler$RunnableTask.run(DefaultSelectorHandler.java:495)

And then, 896 errors were thrown in just one second, and it continued like this for minutes.

This usually happens without consequences, as the connected users can still send and receive data, but sometimes it causes the server to stop communicating.

I am sending the data using getAsyncRemote(), and I usually send them in separate Threads too. (I have a pool of CPU cores * 2 [8] threads I use to handle incoming messages and to prepare the outcoming game data).

Comment by Pavel Bucek [ 09/Aug/16 ]

Can you share a reproducer?

Comment by soylomass [ 09/Aug/16 ]

I wish I could. It happens randomly.

I've changed the async sends for basic instances to see if it stops happening. I'll report.

Comment by soylomass [ 11/Aug/16 ]

Basic of course went even worse, as it isn't efficient to handle a lot of writes.

Pavel, do you have any idea of what could be causing hundreds of those exceptions per second at random times? Do you have any idea of something I could try? My project is stuck until I fix this, and I've tried everything.

Comment by Pavel Bucek [ 12/Aug/16 ]

You could test with different settings related to selector and worker thread pools, see https://tyrus.java.net/apidocs/1.13/org/glassfish/tyrus/container/grizzly/server/GrizzlyServerContainer.html

But I'm not sure whether that will help. The problem seems to be dropped (closed) TCP connections and also it seems like presented exceptions are only consequence, not a cause. Are you monitoring number of open files / sockets on your server? Isn't it close to limits (see ulimit -a on *nix based systems + sysctl -a, etc..).

Comment by soylomass [ 13/Aug/16 ]

Is there any equation to get the recommended number of selector/worker threads? The software is a MMO game sending and receiving from every client more than 10 times per seconds.

By the way, I've set a timeout in the threads who prepare the data for clients and then send it with getAsyncRemote().send, and while the exceptions keep ocurring, the timeout stop it and saves the server from crashing.
It's strange, as the exception should be ocurring in the grizzly thread, not in mine (which I'm terminating)

Comment by petrjanouch [ 14/Aug/16 ]

Hi,

my humble opinion is that this has nothing to do with threads.
Grizzly has a write queue whose content it feeds to a socket when the socket is ready for writing.
The logged error means that Grizzly was not able to send the queued data because the the peer (the client, a load balancer or a proxy if there is one) has closed the TCP connection (look at the java.io.EOFException in the cause).

So I think that you are looking at the wrong side of the connection and the key to solving this is finding out why the connection was closed by the other side.
Btw. By closing the connection I mean that the connection was closed on the TCP level and not gracefully using the Websocket closing handshake.

The only think that puzzles me is that you say that the server becomes unresponsive after this happens. The only reason why Grizzly can become unresponsive is when all its worker threads are blocked somewhere (the exception you posted above wouldn't cause a Grizzly thread to be blocked). When the server becomes unresponsive do a thread dump and see what are Grizzly Worker threads doing or post it here if you cannot figure out anything.

Comment by soylomass [ 14/Aug/16 ]

What puzzles me is why the exception, once it happens, repeats itself hundreds of times in a second, if I don't make that many writes to a single client.

The exception doesn't make the server crash anymore now that I've implemented a timeout in the threads where the getAsyncRemote().send occur, but the exceptions keep happening randomly.

Comment by petrjanouch [ 14/Aug/16 ]

That is strange. The exception is logged once per closed connection and it will be also returned by the future/javax.websocket.SendResult of each uncompleted asynchronously written message.

Are you sure the hundreds of logged messages belong to one connection and many connections are not closed at the same time for whatever reason?

Comment by soylomass [ 14/Aug/16 ]

I would like to check that. I should use Future.get() to know that, right? In that case, the operation will be similar in performance to sending a syncronous write, as it would wait to the write operation to complete?

Comment by soylomass [ 14/Aug/16 ]

EDIT: I've checked the logs once more, and the exceptions start to happen always after a user disconnects (as it's catched by the onClose callback):

Close connection for client:

{80c02da2-e649-4edf-9a1e-6fa70591aef0}

ON CLOSE
Aug 14, 2016 3:51:19 PM org.glassfish.tyrus.container.grizzly.client.GrizzlyWriter$WriterCondition$1 onError
WARNING: Connection closed

So I don't think it has to do with many connections being closed at the same time. But it's still strange why the exception happens more time than the quantity of writes made to that user.

Comment by petrjanouch [ 14/Aug/16 ]

I have just figured out what happened. The message can be really logged enormous amount of times per one closed connection. I will fix it tomorrow morning CET and also a snapshot with the fix should be available tomorrow.

Thanks for reporting this. I will keep you updated about the fix.

Comment by soylomass [ 14/Aug/16 ]

Nice!. I'll look forward for it. Thanks a lot for the quick responses.

Comment by petrjanouch [ 15/Aug/16 ]

OK. Fixed. You can try 1.14-SNAPSHOT or 2.0-SNAPSHOT from java.net maven repo https://maven.java.net/content/repositories/snapshots/org/glassfish/tyrus/
Please, let us know how it worked for you.

Comment by soylomass [ 16/Aug/16 ]

I've updated to 1.14 snapshot and will report the results. What's the difference in 2.0?

Comment by Pavel Bucek [ 16/Aug/16 ]

2.0 is Java 8, 1.14 is Java 7.

But in practice, they are equal - same features, same code. Please use 1.14, since we are not yet releasing 2.x and it's not clear when that will happen.

Comment by soylomass [ 16/Aug/16 ]

Ok.

Can confirm the 1.14 snapshot fixes the problem (the exception now appears only once). Thanks to both of you for the quick help and support.





[TYRUS-428] When java security policy is used, Tyrus requires getProxySelector permission even if no Proxy is set Created: 09/Aug/16  Updated: 09/Aug/16

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: angelhpe Assignee: Pavel Bucek
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JVM with security policy enabled



 Description   

1. Enable java security policy
2. Send a request using Tyrus
3. The request fails with the error below.

The error would indicate that is used, however no proxy is used. It occurs because in JDKClientContainer (line 412) a proxy selector is obtained regardless whether a proxy is needed or not.

final ProxySelector proxySelector = ProxySelector.getDefault();

javax.websocket.DeploymentException: Handshake error.
	at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:674)
	at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
	at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:373)
	at com.hp.oo.connector.client.websocket.tyrus.TyrusWebSocketClientNetConnector.lambda$connect$0(TyrusWebSocketClientNetConnector.java:146)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.AccessControlException: access denied ("java.net.NetPermission" "getProxySelector")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
	at java.security.AccessController.checkPermission(AccessController.java:884)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.net.ProxySelector.getDefault(ProxySelector.java:94)
	at org.glassfish.tyrus.container.jdk.client.JdkClientContainer.processProxy(JdkClientContainer.java:411)
	at org.glassfish.tyrus.container.jdk.client.JdkClientContainer.access$100(JdkClientContainer.java:80)
	at org.glassfish.tyrus.container.jdk.client.JdkClientContainer$1.call(JdkClientContainer.java:139)
	at org.glassfish.tyrus.container.jdk.client.JdkClientContainer$1.call(JdkClientContainer.java:126)
	at org.glassfish.tyrus.container.jdk.client.ClientFilter.processRead(ClientFilter.java:205)
	at org.glassfish.tyrus.container.jdk.client.Filter.onRead(Filter.java:134)
	at org.glassfish.tyrus.container.jdk.client.Filter.onRead(Filter.java:136)
	at org.glassfish.tyrus.container.jdk.client.Filter.onRead(Filter.java:136)
	at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.completed(TransportFilter.java:299)
	at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.completed(TransportFilter.java:283)
	at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)
	at sun.nio.ch.Invoker$2.run(Invoker.java:218)
	at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)
	... 3 more

What's even more curious about this error is that it is thrown when a response is received. Additionally, even if the permission is added, the problem still persists.



 Comments   
Comment by Pavel Bucek [ 09/Aug/16 ]

How do you suggest we get the information about the proxy setting of running JVM?

ProxySelector can return Proxy.NO_PROXY, which suggest that there is no proxy, but Tyrus needs to ask anyway..

Comment by angelhpe [ 09/Aug/16 ]

the problem is a bit different and is two fold:

1) Tyrus asks JVM for a proxy selector even if the end user has not specified any proxy. This can quickly be fixed by getting a proxySelector only if a proxy is in clientProperties. However this is more of a workaround for the actual root cause - see below

2) apparently the thread that is created to handle responses runs into its own security domain; because of this the configuration from java.security policy is not read hence the error above. (even if the getProxySelector permission is added, the error still persists)

Comment by Pavel Bucek [ 09/Aug/16 ]

ad 1) Actually, its the opposite way - when there is no proxy set in ClientProperties, we need to check for proxies defined on JVM level, since Tyrus should honor JVM-wide settings.

ad 2) I'm not sure why the new thread shouldn't have the same security domain - can you please elaborate? Reproducer could be handy..





[TYRUS-427] sending message from Closed Session on Tyrus Client component throw java.lang.IllegalStateException BUT onError is Not called Created: 14/Jul/16  Updated: 14/Jul/16

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.13
Fix Version/s: None

Type: Bug Priority: Major
Reporter: haducloc13 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I tried to send a message from Closed Session (ClientEndpoint). onError was NOT called.

I tried to send a message from Closed Session (ServerEndpoint). onError was called --> Worked.






[TYRUS-426] Support for ephemeral port. Created: 17/Jun/16  Updated: 17/Jun/16  Resolved: 17/Jun/16

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: None
Fix Version/s: 1.13, 2.0

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-418] Problem sending large images (files) Created: 01/Dec/15  Updated: 17/Jun/16  Resolved: 18/Jan/16

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.12
Fix Version/s: 1.13, 2.0

Type: Bug Priority: Major
Reporter: rundgrent Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Triaged

 Description   

I have a small image sending application that works ok with small files, but fails when working with bigger ones. Wondering if this is some kind of setting somewhere or what. I get almost same kind of error in both cases (running as standalone or deployed in Application server. The image is sent by a client (JavaFX) application and it is received on the server (and stored there as a file to verify that it is correct). Then the file is sent to all connected clients where it is displayed.

Error I get with bigger files is as follows:

2015-12-01 15:35:15,694 [grizzly-nio-kernel(2) SelectorRunner] INFO  com.volvo.adt.websocketserver.WebsocketEndPointImage.onClose() - Client disconnected ... removing from session TyrusSession{uri=/websocket/images, id='e9251ffa-8de2-4069-9db5-5b1797871146', endpointWrapper=TyrusEndpointWrapper{endpointClass=null, endpoint=org.glassfish.tyrus.core.AnnotatedEndpoint@764e76ff, contextPath='/websocket', endpointPath=/websocket/images, encoders=[CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpTextCoder, coder=org.glassfish.tyrus.core.coder.NoOpTextCoder@4225658e, type=class java.lang.String}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteBufferCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteBufferCoder@27109b6f, type=class java.nio.ByteBuffer}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteArrayCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteArrayCoder@66854a9f, type=class [B}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.ToStringEncoder, coder=org.glassfish.tyrus.core.coder.ToStringEncoder@63f9213e, type=class java.lang.Object}], decoders=[CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$BooleanDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$BooleanDecoder@a1931da, type=class java.lang.Boolean}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$ByteDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$ByteDecoder@29f10815, type=class java.lang.Byte}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$CharacterDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$CharacterDecoder@65ec7e06, type=class java.lang.Character}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$DoubleDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$DoubleDecoder@4fb65354, type=class java.lang.Double}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$FloatDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$FloatDecoder@c623c99, type=class java.lang.Float}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$IntegerDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$IntegerDecoder@2df23ca0, type=class java.lang.Integer}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$LongDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$LongDecoder@2be87b56, type=class java.lang.Long}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$ShortDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$ShortDecoder@56b9b18c, type=class java.lang.Short}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpTextCoder, coder=org.glassfish.tyrus.core.coder.NoOpTextCoder@4ba2d936, type=class java.lang.String}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteBufferCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteBufferCoder@7789fbde, type=class java.nio.ByteBuffer}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteArrayCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteArrayCoder@1f530cb2, type=class [B}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.ReaderDecoder, coder=org.glassfish.tyrus.core.coder.ReaderDecoder@47dfb05, type=class java.io.Reader}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.InputStreamDecoder, coder=org.glassfish.tyrus.core.coder.InputStreamDecoder@594be9d5, type=class java.io.InputStream}]}}
dec 01, 2015 3:35:15 EM org.glassfish.tyrus.container.grizzly.client.GrizzlyWriter$WriterCondition$1 onError
WARNING: Connection closed
java.io.IOException: Connection closed
	at org.glassfish.grizzly.asyncqueue.TaskQueue.onClose(TaskQueue.java:317)
	at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.onClose(AbstractNIOAsyncQueueWriter.java:501)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.closeConnection(TCPNIOTransport.java:412)
	at org.glassfish.grizzly.nio.NIOConnection.doClose(NIOConnection.java:604)
	at org.glassfish.grizzly.nio.NIOConnection$5.run(NIOConnection.java:570)
	at org.glassfish.grizzly.nio.DefaultSelectorHandler.execute(DefaultSelectorHandler.java:234)
	at org.glassfish.grizzly.nio.NIOConnection.terminate0(NIOConnection.java:564)
	at org.glassfish.grizzly.nio.transport.TCPNIOConnection.terminate0(TCPNIOConnection.java:291)
	at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:136)
	at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:106)
	at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.processAsync(AbstractNIOAsyncQueueWriter.java:344)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:107)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
	at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
	at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
	at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
	at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host
	at sun.nio.ch.SocketDispatcher.write0(Native Method)
	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
	at sun.nio.ch.IOUtil.write(IOUtil.java:51)
	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
	at org.glassfish.grizzly.nio.transport.TCPNIOUtils.flushByteBuffer(TCPNIOUtils.java:149)
	at org.glassfish.grizzly.nio.transport.TCPNIOUtils.writeSimpleBuffer(TCPNIOUtils.java:133)
	at org.glassfish.grizzly.nio.transport.TCPNIOAsyncQueueWriter.write0(TCPNIOAsyncQueueWriter.java:126)
	... 16 more
2015-12-01 15:35:34,348 [Grizzly-worker(8)] FATAL com.volvo.adt.websocketserver.WebsocketEndPointImage.onError() - OnError: TyrusSession{uri=/websocket/images, id='e9251ffa-8de2-4069-9db5-5b1797871146', endpointWrapper=TyrusEndpointWrapper{endpointClass=null, endpoint=org.glassfish.tyrus.core.AnnotatedEndpoint@764e76ff, contextPath='/websocket', endpointPath=/websocket/images, encoders=[CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpTextCoder, coder=org.glassfish.tyrus.core.coder.NoOpTextCoder@4225658e, type=class java.lang.String}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteBufferCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteBufferCoder@27109b6f, type=class java.nio.ByteBuffer}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteArrayCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteArrayCoder@66854a9f, type=class [B}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.ToStringEncoder, coder=org.glassfish.tyrus.core.coder.ToStringEncoder@63f9213e, type=class java.lang.Object}], decoders=[CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$BooleanDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$BooleanDecoder@a1931da, type=class java.lang.Boolean}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$ByteDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$ByteDecoder@29f10815, type=class java.lang.Byte}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$CharacterDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$CharacterDecoder@65ec7e06, type=class java.lang.Character}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$DoubleDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$DoubleDecoder@4fb65354, type=class java.lang.Double}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$FloatDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$FloatDecoder@c623c99, type=class java.lang.Float}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$IntegerDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$IntegerDecoder@2df23ca0, type=class java.lang.Integer}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$LongDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$LongDecoder@2be87b56, type=class java.lang.Long}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.PrimitiveDecoders$ShortDecoder, coder=org.glassfish.tyrus.core.coder.PrimitiveDecoders$ShortDecoder@56b9b18c, type=class java.lang.Short}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpTextCoder, coder=org.glassfish.tyrus.core.coder.NoOpTextCoder@4ba2d936, type=class java.lang.String}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteBufferCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteBufferCoder@7789fbde, type=class java.nio.ByteBuffer}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.NoOpByteArrayCoder, coder=org.glassfish.tyrus.core.coder.NoOpByteArrayCoder@1f530cb2, type=class [B}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.ReaderDecoder, coder=org.glassfish.tyrus.core.coder.ReaderDecoder@47dfb05, type=class java.io.Reader}, CoderWrapper{coderClass=class org.glassfish.tyrus.core.coder.InputStreamDecoder, coder=org.glassfish.tyrus.core.coder.InputStreamDecoder@594be9d5, type=class java.io.InputStream}]}}
java.lang.IllegalStateException: The connection has been closed.
	at org.glassfish.tyrus.core.TyrusSession.checkConnectionState(TyrusSession.java:530)
	at org.glassfish.tyrus.core.TyrusSession.setState(TyrusSession.java:690)
	at org.glassfish.tyrus.core.TyrusEndpointWrapper.onPartialMessage(TyrusEndpointWrapper.java:1073)
	at org.glassfish.tyrus.core.TyrusWebSocket.onFragment(TyrusWebSocket.java:171)
	at org.glassfish.tyrus.core.frame.BinaryFrame.respond(BinaryFrame.java:91)
	at org.glassfish.tyrus.core.ProtocolHandler.process(ProtocolHandler.java:807)
	at org.glassfish.tyrus.core.TyrusWebSocketEngine$TyrusReadHandler.handle(TyrusWebSocketEngine.java:562)
	at org.glassfish.tyrus.container.grizzly.server.GrizzlyServerFilter$ProcessTask.execute(GrizzlyServerFilter.java:379)
	at org.glassfish.tyrus.container.grizzly.client.TaskProcessor.processTask(TaskProcessor.java:114)
	at org.glassfish.tyrus.container.grizzly.client.TaskProcessor.processTask(TaskProcessor.java:91)
	at org.glassfish.tyrus.container.grizzly.server.GrizzlyServerFilter.handleRead(GrizzlyServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
	at java.lang.Thread.run(Thread.java:745)


 Comments   
Comment by Pavel Bucek [ 01/Dec/15 ]

Can you provide small reproducer? What do you use on the client side?

How are you receiving / sending the image? As single big message or as multiple (partial) binary messages?

Comment by rundgrent [ 02/Dec/15 ]

Found out searching in the code that there is a default incoming buffer size that is the limit, DEFAULT_INCOMING_BUFFER_SIZE = 4194315;
I use OutputStream output = session.getBasicRemote().getSendStream() on the client and
session.getAsyncRemote().sendBinary(byteBuffer) on the server (both are JavaSE applications).

How can I change that (buffer limit)?

Comment by Pavel Bucek [ 02/Dec/15 ]

It's not just about this buffer (but it is related).

See https://tyrus.java.net/documentation/1.12/user-guide.html#d0e1197 for details how to change it on client and server.

Anyway, if you are sending the images as a single big message, you might have other issues, like unnecessary memory consumption. I would recommend to explore "partial" messages - you could basically send it as you read it from input stream/file. getSendStream would fork fine, but the implementation does not split the big chunk into several smaller ones - you might need to implement some other logic to do that.

Also, the way how you are receiving this image matter (fi you could share the server-side code, we might be able to give better advice).

Comment by rundgrent [ 02/Dec/15 ]

This is my server code (added the save file thing to verify the image)
@OnMessage
public void processMessage(Session thisSession, ByteBuffer byteBuffer) {
LOGGER.info("Client message {} in session {}", thisSession.getId(), thisSession);
LOGGER.info("Client message size is {}", byteBuffer.array().length);

FileOutputStream fos = null;
File file = new File("D:/download/Image.jpg");
try

{ fos = new FileOutputStream(file); fos.write(byteBuffer.array()); fos.close(); }

catch (FileNotFoundException e)

{ e.printStackTrace(); }

catch (IOException ex) {
LOGGER.error("Exception: {}", ex);
}
for (Session session : sessions)

{ session.setMaxBinaryMessageBufferSize(50000000); session.setMaxIdleTimeout(20000L); session.getAsyncRemote().sendBinary(byteBuffer); }

}

Comment by rundgrent [ 03/Dec/15 ]

When I used the latest (few days old 2.0-SNAPSHOT) I get the buffer overflow error as expected!
Thanks for docs hint!

Comment by Pavel Bucek [ 18/Jan/16 ]

seems like its resolved; feel free to add comment / reopen if you feel otherwise.





[TYRUS-126] websockets api: improve maxMessage description Created: 11/Mar/13  Updated: 16/Jun/16  Resolved: 16/Jun/16

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b13
Fix Version/s: 1.0

Type: Improvement Priority: Major
Reporter: mikc22 Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current maxMessageSize annotation javadoc doesn't say when we can use this annotation and what is the behaviour on specified endpoints. E.g. can I supply maxMessageSize for stream as well ?



 Comments   
Comment by mikc22 [ 11/Mar/13 ]

Should go to websocket spec.





[TYRUS-86] Remove @ApplicationConfig and make scanning algorithm compliant with the spec (@HandlesTypes should work correctly) Created: 07/Feb/13  Updated: 16/Jun/16  Resolved: 09/Feb/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-113] @PathParam does not work for primitive types and boxed types Created: 28/Feb/13  Updated: 16/Jun/16  Resolved: 06/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b13
Fix Version/s: 1.0

Type: Bug Priority: Critical
Reporter: jan.supol Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

javadoc of @PathParam says:

The method parameter may be of type String, any Java primitive type or any boxed version thereof.

However, having:

	@OnMessage
	public String echo(byte b, @PathParam("param") byte param) {
		return String.valueOf(b) + String.valueOf(param);
	}

throws:

Exception: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:439)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$000(AnnotatedEndpoint.java:81)
at org.glassfish.tyrus.core.AnnotatedEndpoint$BasicHandler$1.onMessage(AnnotatedEndpoint.java:526)
at org.glassfish.tyrus.core.SessionImpl.notifyMessageHandlers(SessionImpl.java:309)
at org.glassfish.tyrus.core.EndpointWrapper.onMessage(EndpointWrapper.java:440)
at org.glassfish.tyrus.server.TyrusEndpoint.onMessage(TyrusEndpoint.java:163)
at org.glassfish.tyrus.websockets.DefaultWebSocket.onMessage(DefaultWebSocket.java:138)
at org.glassfish.tyrus.websockets.frametypes.TextFrameType.respond(TextFrameType.java:66)
at org.glassfish.tyrus.websockets.DataFrame.respond(DataFrame.java:102)
at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.onDataAvailable(TyrusHttpUpgradeHandler.java:113)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.processDataAvailable(InputBuffer.java:472)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.onDataAvailable(InputBuffer.java:440)
at org.glassfish.grizzly.http.server.io.InputBuffer.append(InputBuffer.java:844)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:210)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:273)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:820)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)






[TYRUS-81] AnnotatedClassValidityChecker.checkOnMessageReturnType Created: 04/Feb/13  Updated: 16/Jun/16  Resolved: 04/Feb/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Critical
Reporter: Pavel Bucek Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
  • checks decoders type (instead of encoders)
  • forbids everything else than primitive type


 Comments   
Comment by stepan.kopriva [ 04/Feb/13 ]

AnnotatedClassValidityChecker.checkOnMessageReturnType uses encoders instead of decoders.





[TYRUS-84] Update AnnotatedClassValidityChecker to consider Reader and InputStream parameters in methods annotated with @WebSocketMessage Created: 06/Feb/13  Updated: 16/Jun/16  Resolved: 11/Feb/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-87] testSimpleRemoteMT failures Created: 08/Feb/13  Updated: 16/Jun/16  Resolved: 28/Feb/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b10
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by stepan.kopriva [ 28/Feb/13 ]

Used concurrent hash for connection -> webSocketHolder mapping in WebSocektEngine





[TYRUS-88] When n messages from one client are sent to server, WebSocketFiletr.handleRead is invoked more than n times (nondeterministically) Created: 11/Feb/13  Updated: 16/Jun/16  Resolved: 18/Feb/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by stepan.kopriva [ 18/Feb/13 ]

Synchronizing Connection -> WebSocketHolder in WebSocketEngine + making buffer in Masker volatile.





[TYRUS-103] WebSocket in GlassFish 4.0 Promoted Build 72: Unable to Inject CDI or EJB beans Created: 22/Feb/13  Updated: 16/Jun/16  Resolved: 05/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b12
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: peter_pilgrim Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish Embedded Server Promoted 72 with Gradle


Tags: cdi, container, ejb, endpoint, injection, websocket

 Description   

I am reviewing the WebSockets bundled in the GlassFish 4.0 promoted
build 72. I have successfully got a deployed WAR running in GlassFish
embedded container using Gradle.

Does the WebSockets implementation in this promoted build work
currently against CDI?

I tried the following code:

@ApplicationScoped
class SampleBean {
@PostConstruct public void init() { System.out.printtf("%s.init()
called\n", getClass().getSimpleName() );
public getValue()

{ return "whatever"; }

}

@WebSockedEndpoint( "/test" )
class SampleEndPoint {

@Inject @ApplicationScoped private SampleBean sampleBean;

@PostConstruct public void init()

{ System.out.printtf("%s.init() called\n", getClass().getSimpleName() ); // sampleBean is null }

@WebSocketMessage
public String echo(String message)

{ return "ECHO: " + message + " and CDI injected bean was "+sampleBean; // sampleBean is still null }

}

So far, CDI (or the WELD implementation) does not appear to inject any
type of bean, including Application Scoped beans, in to an Endpoint.
Is this a limitation of the current Tyrus reference implementation? Or
is it part of the Web Socket spec?

In fact, I never see SampleBean being initialised at all in the
console output. Strange.

Running the same code with a Servlet instead of a WebSocketEndPoint is successfully.

I also attempted injecting a @Singleton @Startup EJB instance into the WebSocket that also failed



 Comments   
Comment by peter_pilgrim [ 22/Feb/13 ]

PS: Programmatic JNDI look-up does work with EJB. The Tyrus implementation is missing the appropriate hooks in to CDI and EJB containers for post initialisation of the endpoints.

Comment by Pavel Bucek [ 22/Feb/13 ]

can you please retry with newer glassfish version? please make sure it contains latest stable Tyrus (1.0-b11)

unzip -p ./glassfish4/glassfish/modules/tyrus-core.jar META-INF/MANIFEST.MF | grep ^Bundle-Version

Comment by peter_pilgrim [ 24/Feb/13 ]

I tried with the sample code against the latest GlassFish 4.0 b77
I am getting know a different error.

javax.websocket.DeploymentException: Class javax.websocket.server.DefaultServerConfiguration couldn't be instantiated

The Tyrus container is failing and preventing the webapp being deployed.

Comment by Pavel Bucek [ 24/Feb/13 ]

looks like you might have similar problem as described in http://java.net/jira/browse/TYRUS-102

can you confirm tyrus version as I requested in previous comment? Also can you please make sure that you don't include any related API jar in your war file?

Comment by peter_pilgrim [ 25/Feb/13 ]

You were correct. I had to exclude the Java EE API from the WAR file, for example Gradle

dependencies

{ providedCompile 'org.glassfish.main.extras:glassfish-embedded-all:4.0-b77' providedCompile 'javax:javaee-api:7.0-b77' ... }

I checked that b77 of GlassFish embedded server JAR. Indeed, it does refer to Tyrus 1.0-b11

META-INF/org.glassfish.tyrus.tyrus-client/pom.properties
#Generated by org.apache.felix.bundleplugin
#Tue Feb 12 22:34:00 UTC 2013
version=1.0-b11
groupId=org.glassfish.tyrus
artifactId=tyrus-core

I can confirmed CDI injection is working at last.

Now here is the thing. EJB injection does not work at all. Is it suppose to in the WebSocket specification?

Here is a sample endpoint

@WebSocketEndpoint("/singleton")
public class SingletonEJBWebSocketEndpoint {

@EJB
private SampleSingleton sampleSingleton;

@WebSocketOpen
public void open(Session session) {
System.out.printf("%s.open() called session=%s\n", getClass().getSimpleName(), session );

// This is a work around
System.out.printf(" sampleSingleton = %s BEFORE\n", sampleSingleton );
if ( sampleSingleton == null) {
// Look up the object
Context initialContext = null;
try

{ initialContext = new InitialContext(); Object obj = initialContext.lookup("java:global/mywebapp/SampleSingleton"); System.out.printf(" obj=%s\n", obj); sampleSingleton = (SampleSingleton)obj; }

catch (NamingException e)

{ e.printStackTrace(); }

}
System.out.printf(" sampleSingleton = %s AFTER\n", sampleSingleton );
}

@WebSocketClose
public void close(Session session)

{ System.out.printf("%s.close() called session=%s\n", getClass().getSimpleName(), session); System.out.printf(" sampleSingleton = %s\n", sampleSingleton ); }

@WebSocketMessage
public String generateReply( String message )

{ return String.format("%s - name: %s, counter: %d, message:%s", new Date(), sampleSingleton.getFullName(), sampleSingleton.count(), message.toUpperCase()); }

}

The singleton EJB is:

package je7hb.websocket.basic;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.Singleton;
import javax.ejb.Startup;
import java.util.concurrent.atomic.AtomicInteger;

@Singleton
@Startup
public class SampleSingleton {
private AtomicInteger counter = new AtomicInteger(5000);
@PostConstruct
public void init()

{ System.out.printf(">>>> %s.init() called\n", getClass().getSimpleName()); }

@PreDestroy
public void destroy()

{ System.out.printf(">>>> %s.destroy() called\n", getClass().getSimpleName()); }

public int count()

{ return counter.getAndAdd(2); }

public String getFullName()

{ return "Peter Pilgrim"; }

}

The output for the standard console is thus:

NFO: mywebapp was successfully deployed in 2,083 milliseconds.

        • Press the ENTER key to stop the server ****
          No valid EE environment for injection of je7hb.websocket.basic.SingletonEJBWebSocketEndpoint
          SingletonEJBWebSocketEndpoint.open() called session=Session(1280588945, true)
          sampleSingleton = null BEFORE
          obj=je7hb.websocket.basic.SampleSingleton@41849a6a
          sampleSingleton = je7hb.websocket.basic.SampleSingleton@41849a6a AFTER
          SingletonEJBWebSocketEndpoint.close() called session=Session(1280588945, true)
          sampleSingleton = je7hb.websocket.basic.SampleSingleton@41849a6a
          > Building > :run

The EJB should inject especially if it is running in the same JVM. For Servlets I check that EJB can inject as well.

@WebServlet("/fake")
public class FakeServlet extends HttpServlet

{ @EJB SampleSingleton sampleSingleton; ... }
Comment by stepan.kopriva [ 05/Mar/13 ]

According to specificitaion: "Websocket endpoints running in the Java EE platform must have full dependency injection support as described in the CDI specification [8]. [WSC-7.1.1-1] Websocket implementations part of the Java EE platform are required to support field, method, and constructor injection using the javax.inject.Inject annotation into all web socket endpoint classes, as well as the use of interceptors for these classes".

We do currently also support EJB annotations on endpoint, so your endpoint could look like this:

@ServerEndpoint(value = "/stateful")
@Stateful
public class StatefulBean {

int counter = 0;
private boolean postConstructCalled = false;

@OnMessage
public String echo(String message)

{ return postConstructCalled ? String.format("%s%s", message, counter++) : "PostConstruct not called."; }

@PostConstruct
public void postConstruct()

{ postConstructCalled = true; }

}

To inject the EJB to an endpoint please use the @Inject annotation.





[TYRUS-107] IlegalStateException logged in server log when CDI interceptor is deployed on GF Created: 25/Feb/13  Updated: 16/Jun/16  Resolved: 20/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b11
Fix Version/s: 1.0

Type: Bug Priority: Minor
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to GLASSFISH-19961 ServletContext#addFilter(String, Filt... Resolved

 Description   

Deployed a POJO endpoint as defined at:

@WebSocketEndpoint(value="/websocket-cdi")
@Logging
public class MyEndpointWithCDI {

@Inject MyBean bean;

@WebSocketMessage
public String sayHello(String name)

{ return bean.sayHello(name); }

}

@Logging is a standard CDI interceptor with @AroundInvoke and MyBean is a POJO. Deploying this application throws the following exception:

INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@361cb3dd
INFO: Closing down : org.glassfish.tyrus.server.TyrusEndpoint@23a18c70
SEVERE: Exception during invocation of InjectionManager.destroyManagedObject on org.glassfish.tyrus.servlet.TyrusServletFilter@2add39c5 of web module StandardEngine[glassfish-web].StandardHost[server].StandardContext[/injection]
java.lang.IllegalStateException: Unknown JCDI-enabled managed bean org.glassfish.tyrus.servlet.TyrusServletFilter@2add39c5 of class class org.glassfish.tyrus.servlet.TyrusServletFilter
at com.sun.enterprise.container.common.impl.managedbean.ManagedBeanManagerImpl.destroyManagedBean(ManagedBeanManagerImpl.java:622)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:439)
at com.sun.enterprise.container.common.impl.util.InjectionManagerImpl.destroyManagedObject(InjectionManagerImpl.java:414)
at com.sun.web.server.WebContainerListener.preDestroy(WebContainerListener.java:186)
at com.sun.web.server.WebContainerListener.containerEvent(WebContainerListener.java:151)
at org.apache.catalina.core.ContainerBase.fireContainerEvent(ContainerBase.java:1579)
at org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:334)
at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:5322)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6085)

Invoking the endpoint throws the following message in server.log:

SEVERE: No valid EE environment for injection of org.glassfish.injection.MyEndpointWithCDI
SEVERE: No valid EE environment for injection of org.glassfish.injection.MyBean

However the communication between client and endpoint works as expected.



 Comments   
Comment by arungupta [ 25/Feb/13 ]

Thanks Stepan for filing the issue.

Comment by arungupta [ 28/Feb/13 ]

Tried with b78, even though the following warning messages are still shown:

SEVERE: No valid EE environment for injection of org.glassfish.tyrus.core.NoOpTextCoder
SEVERE: No valid EE environment for injection of org.glassfish.tyrus.core.ReaderDecoder
SEVERE: No valid EE environment for injection of org.glassfish.injection.MyEndpointWithEJB
WARNING: Method destroy defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PreDestroy, but is defined on the target class and does not have 0 arguments
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: Method init defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PostConstruct, but is defined on the target class and does not have 0 arguments
WARNING: Method destroy defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PreDestroy, but is defined on the target class and does not have 0 arguments
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: WELD-001450 Interceptor method public java.lang.Object com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(javax.interceptor.InvocationContext) throws java.lang.Throwable does not declare that it throws Exception.
WARNING: Method init defined on class com.sun.ejb.containers.interceptors.SystemInterceptorProxy will not be used for interception, since it is not defined according to the specification. It is annotated with @javax.annotation.PostConstruct, but is defined on the target class and does not have 0 arguments
SEVERE: No valid EE environment for injection of org.glassfish.tyrus.core.NoOpTextCoder
SEVERE: No valid EE environment for injection of org.glassfish.tyrus.core.ReaderDecoder
SEVERE: No valid EE environment for injection of org.glassfish.injection.MyEndpointWithCDI
SEVERE: No valid EE environment for injection of org.glassfish.injection.MyBean

But the injection and invocation of injected beans is working.

Comment by stepan.kopriva [ 20/Mar/13 ]

Fixed. TyrusServletFilter is now created via ServletContext#createFilter.

The general problem is being tracked under http://java.net/jira/browse/GLASSFISH-19961





[TYRUS-110] @OnMessage with arguments (byte[], boolean), or (ByteBuffer, boolean) does return any value Created: 27/Feb/13  Updated: 16/Jun/16  Resolved: 01/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b13
Fix Version/s: 1.0

Type: Bug Priority: Critical
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

WebSocketMessage javadoc says:

The allowed parameters are:
byte[] and boolean pair, or ByteBuffer and boolean pair to receive the message in parts
and an optional Session parameter.

the following method:

	@OnMessage
	public String bytesToString(byte[] array, boolean finito) {
		return new String(array);
	}

or

	@OnMessage
	public String echo(ByteBuffer buf, boolean bol) {
		return new String(buf.array());
	}

does not return any value, although javadoc permits it. This is a binary variant of TYRUS-105



 Comments   
Comment by Pavel Bucek [ 01/Mar/13 ]

already fixed as part of TYRUS-105.

commit relevant to this issue just adds more tests.





[TYRUS-111] @OnMessage with arguments (byte[], Session, boolean) does return any value Created: 27/Feb/13  Updated: 16/Jun/16  Resolved: 05/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b13
Fix Version/s: 1.0

Type: Bug Priority: Critical
Reporter: jan.supol Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following endpoint:

@ServerEndpoint(value = "/partialbytearraysession")
public class WSByteArrayPartialAndSessionServer {

	StringBuffer sb = new StringBuffer();
	
	@OnMessage
	public void bytesToString(byte[] array, Session s, boolean finito) throws IOException {
		sb.append(new String(array)).append("(").append(finito).append(")");
		if (finito){
			s.getBasicRemote().sendText(sb.toString());
			sb = new StringBuffer();
		}
	}
}	

does not respond to

 RemoteEndpoint.Basic.sendBinary( ByteBuffer.wrap("first".getBytes()) , false)
 RemoteEndpoint.Basic.sendBinary( ByteBuffer.wrap("second".getBytes()) , true)

In the gf log, there is:

[#|2013-02-27T19:07:15.349+0100|SEVERE|glassfish 4.0|org.glassfish.tyrus.core.SessionImpl|_ThreadID=86;_ThreadName=http-listener-1(3);_TimeMillis=1361988435349;_LevelValue=1000;|Unhandled text message in EndpointWrapper|#]

It seems there is some binary vs. text message confusion



 Comments   
Comment by stepan.kopriva [ 05/Mar/13 ]

Solved with switching to WebSocket SPEC API v14





[TYRUS-116] Implement proper handling of Reader and InputStream (as params of @OnMessage) Created: 01/Mar/13  Updated: 16/Jun/16  Resolved: 12/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Critical
Reporter: Pavel Bucek Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks TYRUS-50 BlockingBinaryTest receiving chunks o... Resolved
Duplicate
is duplicated by TYRUS-43 MessageHandler.CharacterStream onMess... Resolved
Related
is related to TYRUS-114 Implement caching of partial messages... Resolved




[TYRUS-119] Validation algorithm for registering MessageHandlers (also applied to check validity of @OnMessage in annotated cases) does not work as specified in WebSocket API 13 Created: 01/Mar/13  Updated: 16/Jun/16  Resolved: 04/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by stepan.kopriva [ 04/Mar/13 ]

Validation algorithm complies to spec v 13





[TYRUS-147] Falling lifecycle test on Internet Explorer Created: 20/Mar/13  Updated: 16/Jun/16  Resolved: 20/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by stepan.kopriva [ 20/Mar/13 ]

Fixed. The problem was in the test javascript code.





[TYRUS-151] Getting java.nio.BufferUnderflowException or sometimes NPE in InputStream onMessage() communication Created: 20/Mar/13  Updated: 16/Jun/16  Resolved: 21/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Bug Priority: Major
Reporter: mikc22 Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The following test:

mvn -Dtest=LifeCycleAnnotatedObjectInputStreamTest clean install

is sometimes causing this exception to happen or alternatively NPE thrown @org.glassfish.tyrus.core.InputStreamBuffer.getNextByte(InputStreamBuffer.java:99)

java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Buffer.java:492)
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135)
at org.glassfish.tyrus.core.InputStreamBuffer.getNextByte(InputStreamBuffer.java:99)
at org.glassfish.tyrus.core.BufferedInputStream.read(BufferedInputStream.java:65)
at java.io.InputStream.read(InputStream.java:179)
at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2283)
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2296)
at java.io.ObjectInputStream$BlockDataInputStream.readUTFBody(ObjectInputStream.java:3036)
at java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:2837)
at java.io.ObjectInputStream.readString(ObjectInputStream.java:1617)
at java.io.ObjectInputStream.readTypeString(ObjectInputStream.java:1419)
at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:692)
at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java:827)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1750)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.ObjectInputStreamSessionImpl.onServerMessageHandler(ObjectInputStreamSessionImpl.java:94)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.ObjectInputStreamSessionImpl.onServerMessageHandler(ObjectInputStreamSessionImpl.java:58)
at org.glassfish.tyrus.tests.qa.lifecycle.SessionLifeCycle.onServerMessage(SessionLifeCycle.java:143)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.binary.AnnotatedWholeMessageObjectInputStreamSession$Server.onMessage(AnnotatedWholeMessageObjectInputStreamSession.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:431)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$100(AnnotatedEndpoint.java:83)
at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:518)
at org.glassfish.tyrus.core.InputStreamBuffer$1.run(InputStreamBuffer.java:134)
Mar 20, 2013 7:30:21 PM org.glassfish.tyrus.tests.qa.lifecycle.SessionLifeCycle onServerMessage
SEVERE: null
java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Buffer.java:492)
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:135)
at org.glassfish.tyrus.core.InputStreamBuffer.getNextByte(InputStreamBuffer.java:99)
at org.glassfish.tyrus.core.BufferedInputStream.read(BufferedInputStream.java:65)
at java.io.InputStream.read(InputStream.java:179)
at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2283)
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2296)
at java.io.ObjectInputStream$BlockDataInputStream.readUTFBody(ObjectInputStream.java:3036)
at java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:2837)
at java.io.ObjectInputStream.readString(ObjectInputStream.java:1617)
at java.io.ObjectInputStream.readTypeString(ObjectInputStream.java:1419)
at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:692)
at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java:827)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1514)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1750)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1347)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.ObjectInputStreamSessionImpl.onServerMessageHandler(ObjectInputStreamSessionImpl.java:94)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.ObjectInputStreamSessionImpl.onServerMessageHandler(ObjectInputStreamSessionImpl.java:58)
at org.glassfish.tyrus.tests.qa.lifecycle.SessionLifeCycle.onServerMessage(SessionLifeCycle.java:143)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.binary.AnnotatedWholeMessageObjectInputStreamSession$Server.onMessage(AnnotatedWholeMessageObjectInputStreamSession.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:431)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$100(AnnotatedEndpoint.java:83)
at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:518)
at org.glassfish.tyrus.core.InputStreamBuffer$1.run(InputStreamBuffer.java:134)



 Comments   
Comment by stepan.kopriva [ 21/Mar/13 ]

Fixed by synchronizing InputStreamBuffer





[TYRUS-195] Repair the ReaderBuffer (concurrency issue) Created: 17/Jun/13  Updated: 16/Jun/16  Resolved: 17/Jun/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.1

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





Implement all setable timeouts (TYRUS-130)

[TYRUS-139] Implement timeout on Session Created: 14/Mar/13  Updated: 16/Jun/16  Resolved: 18/Mar/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Sub-task Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-64] Get rid of @ApplicationConfig once http://java.net/jira/browse/GLASSFISH-19551 is solved Created: 18/Jan/13  Updated: 16/Jun/16  Resolved: 09/Feb/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on GLASSFISH-19551 ServletContainerInitializer#onStartup... Resolved




[TYRUS-174] Create documentation for samples (in readme) Created: 22/Apr/13  Updated: 16/Jun/16  Resolved: 22/Apr/13

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Task Priority: Major
Reporter: stepan.kopriva Assignee: stepan.kopriva
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-425] Reconnect Handler problem Created: 01/Jun/16  Updated: 01/Jun/16

Status: Open
Project: tyrus
Component/s: core
Affects Version/s: 1.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hugolarson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

Hello,

Sometimes Tomcat (7.0.69) throw a IOException: Connection timed out sporadically. OnError is called on the server side and I close the connection but the Tyrus ReconnectHandler does not reconnect at all with this particular exception. I have set the hearbeat interval to 1 minute.

BR,
Hugo






[TYRUS-424] Error in Deployment Algorithm description. Created: 09/May/16  Updated: 09/May/16

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: pacuk.anton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tyrus documentation 1.12
https://tyrus.java.net/documentation/1.12/index/deployment.html



 Description   
public class MyApplicationConfigOne implements ServerApplicationConfig {
    public Set<ServerEndpointConfig> getEndpointConfigs(Set<Class<? extends Endpoint>> endpointClasses);
        Set<Class<? extends Endpoint>> s = new HashSet<Class<? extends Endpoint>>;
        s.add(ProgrammaticEndpointOne.class);
        return s;
    }

    public Set<Class> getAnnotatedEndpointClasses(Set<Class<?>> scanned);
       Set<Class<?>> s = new HashSet<Class<?>>;
        s.add(AnnotatedEndpointOne.class);
        return s;
    }
}

Set<Class<? extends Endpoint>> is returned instead of Set<ServerEndpointConfig> in getEndpointConfigs



 Comments   
Comment by pacuk.anton [ 09/May/16 ]

Wrong class name:

If one or more classes implementing ServerApplicationConfiguration are present in the WAR file, Tyrus deploys endpoints provided by all of these classes. Tyrus doesn't deploy any other classes present in the WAR (annotated by javax.websocket.server.ServerEndpoint or extending javax.websocket.Endpoint).
If no class implementing ServerApplicationConfiguration is present, Tyrus deploys all classes annotated with @ServerEndpoint or extending Endpoint present in the WAR.





[TYRUS-423] java.nio.BufferUnderflowException when receiving gzipped Inputstream Created: 09/May/16  Updated: 09/May/16

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hugolarson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows



 Description   

Hello,

We have an application that connects to Tomcat for receiving and sending request.
I have moved from receiving and sending to InputStream from ByteBuffer.
I discovered that Tyrus have problem receiving Gzipped Inputstream.
I find it also strange that the exception is generated in ByteBuffer class when im working with streams.
I can receive gzipped streams in Tomcat without problem and it works without gzip.

java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Unknown Source)
at java.nio.HeapByteBuffer.get(Unknown Source)
at org.glassfish.tyrus.core.InputStreamBuffer.getNextByte(InputStreamBuffer.java:130)
at org.glassfish.tyrus.core.BufferedInputStream.read(BufferedInputStream.java:66)
at java.io.InputStream.read(Unknown Source)
at java.util.zip.InflaterInputStream.fill(Unknown Source)
at java.util.zip.InflaterInputStream.read(Unknown Source)
at java.util.zip.GZIPInputStream.read(Unknown Source)
at java.io.ObjectInputStream$PeekInputStream.read(Unknown Source)
at java.io.ObjectInputStream$PeekInputStream.readFully(Unknown Source)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(Unknown Source)
at java.io.ObjectInputStream.readStreamHeader(Unknown Source)
at java.io.ObjectInputStream.<init>(Unknown Source)
at advit.web.dxweb.DxService.handleIn(DxService.java:26)
at advit.web.dxweb.TyrusWsClient$MyMessageHandler.handleMessage(TyrusWsClient.java:293)
at advit.web.dxweb.TyrusWsClient.onMessage(TyrusWsClient.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:477)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$100(AnnotatedEndpoint.java:87)
at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:573)
at org.glassfish.tyrus.core.InputStreamBuffer$1.run(InputStreamBuffer.java:180)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

----------------------------For sending from Tomcat:
WsPayLoad payl = new WsPayLoad();
try (ObjectOutputStream ous = new ObjectOutputStream(new GZIPOutputStream(sess.getBasicRemote().getSendStream()))

{ ous.writeObject(payl); ous.flush(); }

----------------------For receiving on Tyrus client:
@Override
public void handleMessage(InputStream ins)

{ ObjectInputStream in = new ObjectInputStream( new GZIPInputStream(ins);); WsPayLoad obj = in.readObject();//Exception thrown here }




[TYRUS-422] Data lost when using SSL and unconsumed data pending when socket closes Created: 29/Mar/16  Updated: 29/Mar/16

Status: Open
Project: tyrus
Component/s: protocol
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: spatula Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This behavior was observed when connecting to a RabbitMQ server running a WebStomp plugin, and the connection was forcibly closed using RabbitMQ's admin UI. There are probably other, simpler ways to duplicate it. The sequence of events is that RabbitMQ sends an ERROR stomp frame and then quickly disconnects the connection.

When connecting via SSL (ie, with a wss:// URL), the ERROR frame sent across the WebSocket prior to disconnection is never delivered (ie, through TyrusWebSocket.onMessage); however, when connecting unencrypted (ie, with a ws:// URL), the ERROR frame sent prior to disconnection does get delivered.

It appears as though this may be a timing-sensitive issue, and the fact that it takes more time to decrypt the SSL data means that the close event gets handled first, and consequently the data is dropped, rather than handled.

I'm afraid I don't know Tyrus/Grizzly's internals well enough to speculate on how a fix might be implemented to ensure that any pending data was consumed from the WebSocket prior to firing events related to the socket closure.



 Comments   
Comment by spatula [ 29/Mar/16 ]

Explicitly specifying grizzly-framework version 2.3.22 seems to cure this ailment so far.





[TYRUS-402] Unable to use Tyrus in android appllication - Still broken Created: 23/Jul/15  Updated: 25/Mar/16  Resolved: 12/Aug/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8.3
Fix Version/s: 1.12

Type: Bug Priority: Major
Reporter: ymenager Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Android 4.2.2


Issue Links:
Cloners
clones TYRUS-387 Unable to use Tyrus in android applli... Resolved
Duplicate
duplicates TYRUS-386 Dalvik class loader rejects TyrusEnpo... Resolved
is duplicated by TYRUS-403 tyrus client broken on android with SSL Resolved

 Description   

I am using tyrus client library on android, but runtime error occurs. See details from logcat below. The same scenario works with Tyrus 1.7.

I/SurfaceFlinger( 303): id=58(15) createSurf 0x410803c4 (1x1),2 flag=404, iellotyrus
I/MainActivity( 5391): Hello Tyrus started!
I/MainActivity( 5391): Hello Tyrus thread running!
I/dalvikvm( 5391): Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1616 'Lorg/osgi/framework/SynchronousBundleListener;'
W/dalvikvm( 5391): Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
I/dalvikvm( 5391): Could not find method org.glassfish.tyrus.core.OsgiRegistry.getInstance, referenced from method org.glassfish.tyrus.core.ReflectionHelper.getOsgiRegistryInstance
W/dalvikvm( 5391): VFY: unable to resolve static method 10918: Lorg/glassfish/tyrus/core/OsgiRegistry;.getInstance ()Lorg/glassfish/tyrus/core/OsgiRegistry;
I/dalvikvm( 5391): Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1616 'Lorg/osgi/framework/SynchronousBundleListener;'
W/dalvikvm( 5391): Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
W/dalvikvm( 5391): VFY: unable to find class referenced in signature (Lorg/glassfish/tyrus/core/OsgiRegistry
W/dalvikvm( 5391): VFY: rejected Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;.<init> (Ljavax/websocket/Endpoint;Ljava/lang/Class;Ljavax/websocket/EndpointConfig;Lorg/glassfish/tyrus/core/ComponentProviderService;Ljavax/websocket/WebSocketContainer;Ljava/lang/String;Ljavax/websocket/server/ServerEndpointConfig$Configurator;Lorg/glassfish/tyrus/core/TyrusEndpointWrapper$SessionListener;Lorg/glassfish/tyrus/core/cluster/ClusterContext;Lorg/glassfish/tyrus/core/monitoring/EndpointEventListener;Ljava/lang/Boolean;)V
W/dalvikvm( 5391): VFY: rejected Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;.<init> (Ljavax/websocket/Endpoint;Ljava/lang/Class;Ljavax/websocket/EndpointConfig;Lorg/glassfish/tyrus/core/ComponentProviderService;Ljavax/websocket/WebSocketContainer;Ljava/lang/String;Ljavax/websocket/server/ServerEndpointConfig$Configurator;Lorg/glassfish/tyrus/core/TyrusEndpointWrapper$SessionListener;Lorg/glassfish/tyrus/core/cluster/ClusterContext;Lorg/glassfish/tyrus/core/monitoring/EndpointEventListener;Ljava/lang/Boolean;)V
W/dalvikvm( 5391): Verifier rejected class Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;
I/SurfaceFlinger( 303): id=58 Removed iellotyrus (4/5)
I/SurfaceFlinger( 303): id=58 Removed iellotyrus (-2/5)



 Comments   
Comment by ymenager [ 23/Jul/15 ]

Err.... I think clone might not have been the option i was looking for... sorry if that's the case.

Anyways, this is still broken on latest 1.11 against android 5.0.

I've run a debugger and when it hits the wrap method, the source byte array is 4 long, but only the 1st one has anything (the other 3 are null), which breaks everything

Comment by ymenager [ 23/Jul/15 ]

It really would be safer to add to do a "cleanup" of the byte array before sending to the engine, that way you can make sure this doesn't happen again.

I'm probably going to have to do a fork to make myself a fixed version, so I'll push the change

Comment by ymenager [ 24/Jul/15 ]

Doing the following seems to fix the problem. I've had to do some major acrobatics in order to be able to override SSLEngine since grizzly makes overriding anything around there near impossible.

@Override
public SSLEngineResult wrap(ByteBuffer[] srcs, int offset, int length, ByteBuffer dst) throws SSLException {
ArrayList<ByteBuffer> list = new ArrayList<ByteBuffer>();
for (ByteBuffer bb : srcs) {
if( bb != null )

{ list.add(bb); }

}
return wrapped.wrap(list.toArray(new ByteBuffer[list.size()]), offset, length, dst);
}

Comment by petrjanouch [ 12/Aug/15 ]

This is a bug in Android 5.0. They do the validation of input in SSLEngine incorrectly.

Grizzly 2.3.22 that has just been released includes a workaround for it. I have tested it and it works.

So until the next Tyrus version is released, just replace currently used version of Grizzly with 2.3.22.

Comment by diwakargoel [ 11/Mar/16 ]

Hi,

Could you share the sample you used to test on Android 5.0?

I get the following exception:

03-10 16:54:34.313 22609-23507/oracle.wsc.samples.android W/System.err: FINE: GRIZZLY0013: Exception during FilterChain execution
03-10 16:54:34.313 22609-23507/oracle.wsc.samples.android W/System.err: Throwable occurred: javax.net.ssl.SSLHandshakeException: Handshake failed
03-10 16:54:34.313 22609-23507/oracle.wsc.samples.android W/System.err:     at com.android.org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:436)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:1006)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLUtils.sslEngineUnwrap(SSLUtils.java:460)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLConnectionContext.unwrap(SSLConnectionContext.java:189)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLUtils.handshakeUnwrap(SSLUtils.java:286)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:634)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLFilter.doHandshakeStep(SSLFilter.java:330)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:583)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:304)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
03-10 16:54:34.318 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err:     at java.lang.Thread.run(Thread.java:818)
03-10 16:54:34.319 22609-23507/oracle.wsc.samples.android W/System.err: Caused by: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0xa3a0f800: Failure in SSL library, usually a protocol error
03-10 16:54:34.320 22609-23507/oracle.wsc.samples.android W/System.err: error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message (external/openssl/ssl/s3_both.c:498 0xae243ce0:0x00000000)
03-10 16:54:34.320 22609-23507/oracle.wsc.samples.android W/System.err:     at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake_bio(Native Method)
03-10 16:54:34.320 22609-23507/oracle.wsc.samples.android W/System.err:     at com.android.org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:423)
03-10 16:54:34.320 22609-23507/oracle.wsc.samples.android W/System.err: 	... 22 more

As you can see org.glassfish.grizzly.ssl.SSLConnectionContext.unwrap(SSLConnectionContext.java:189) is called regardless and as the output.isComposite is always false.

The following line gets called:

SSLConnectionContext.java:189
sslEngineResult = sslEngineUnwrap(sslEngine, inputByteBuffer,
                        output.toByteBuffer());

instead of

SSLConnectionContext.java:198
sslEngineResult = sslEngineUnwrap(sslEngine, inputByteBuffer,
                            outputArray, 0, bba.size());

which actually has the ANDROID_WORKAROUND_NEEDED logic.

Comment by petrjanouch [ 13/Mar/16 ]

Hi,

first about the test application. I took the client code form Tyrus echo sample (https://github.com/tyrus-project/tyrus/blob/master/samples/echo/src/test/java/org/glassfish/tyrus/sample/echo/EchoTest.java), put it into android app and pointed at wss://echo.websocket.org.
It is a very simplistic test, but it reliably reproduced the problem and now it does not.

I think you are experiencing another issue that is not related to the original bug. Your reasoning about Grizzly taking an incorrect path is wrong.
SSSEngine#wrap/unwap have 2 versions - one taking ByteBuffer and another an array of ByteBuffers. Only the version with an array is broken in Android 5.
Grizzly uses 2 types of buffers composite and non composite depending on what is more optimal in the given situation. If it uses a composite buffer, it calls the version of wrap/unwrap method with ByteBuffer array parameter. The fix is only in the "composite path", because the "non composite path" aways worked. That is why your reasoning that it takes the path in the stack trace that doesn't have the fix is wrong. It takes the path that always worked.

It is true that the original bug had the same exception / stack trace, but the cause was a NPE form OpenSSLEngineImpl that occurred the previous call to SSLEngine. If you don't see such a NPE form OpenSSLEngineImpl in your logs, it is not related.

It might be that the OpenSSL on the client just doesn't like what the sever is sending. I would like to help, but I need more information.

Comment by diwakargoel [ 14/Mar/16 ]

Hi,

Thanks for your reply!

Then this is a new bug as this manifests itself in the "non composite path" which is indicated by the following line in the stacktrace SSLConnectionContext.java:189

I just tried a bare-bone Android app which gives the following exception connecting to wss://echo.websocket.org.

03-13 18:53:56.385 8027-8054/android.hellotyrus E/MainActivity: Error
                                                                javax.websocket.DeploymentException: SSL handshake has failed
                                                                    at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:396)
                                                                    at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.access$000(GrizzlyClientSocket.java:103)
                                                                    at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:235)
                                                                    at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:231)
                                                                    at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.connect(GrizzlyClientSocket.java:249)
                                                                    at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer.openClientSocket(GrizzlyClientContainer.java:95)
                                                                    at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:663)
                                                                    at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
                                                                    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
                                                                    at java.util.concurrent.FutureTask.run(FutureTask.java:237)
                                                                    at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
                                                                    at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:81)
                                                                    at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
                                                                    at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:355)
                                                                    at android.hellotyrus.MainActivity$HelloThread.run(MainActivity.java:60)
                                                                 Caused by: javax.net.ssl.SSLHandshakeException: Handshake failed
                                                                    at com.android.org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:436)
                                                                    at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:1006)
                                                                    at org.glassfish.grizzly.ssl.SSLUtils.sslEngineUnwrap(SSLUtils.java:460)
                                                                    at org.glassfish.grizzly.ssl.SSLConnectionContext.unwrap(SSLConnectionContext.java:189)
                                                                    at org.glassfish.grizzly.ssl.SSLUtils.handshakeUnwrap(SSLUtils.java:286)
                                                                    at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:634)
                                                                    at org.glassfish.grizzly.ssl.SSLFilter.doHandshakeStep(SSLFilter.java:330)
                                                                    at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:583)
                                                                    at org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:304)
                                                                    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
                                                                    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
                                                                    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
                                                                    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
                                                                    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
                                                                    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
                                                                    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:536)
                                                                    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
                                                                    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
                                                                    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
                                                                    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
                                                                    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:591)
                                                                    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:571)
                                                                    at java.lang.Thread.run(Thread.java:818)
                                                                 Caused by: javax.net.ssl.SSLProtocolException: SSL handshake terminated: ssl=0xa6dd8a00: Failure in SSL library, usually a protocol error
                                                                error:1408E0F4:SSL routines:SSL3_GET_MESSAGE:unexpected message (external/openssl/ssl/s3_both.c:498 0xae264ce0:0x00000000)
                                                                    at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake_bio(Native Method)
                                                                    at com.android.org.conscrypt.OpenSSLEngineImpl.unwrap(OpenSSLEngineImpl.java:423)
                                                                    	... 22 more

This is when trying to connect over wss on a simulator with Target: Google APIs (API level 21). The same app works fine both ws/wss over a device with API level 22.

Is there a way to force the "composite" path? Do let me know if you need any more information.
Thanks!

Comment by petrjanouch [ 14/Mar/16 ]

Ok that explains it. I reproduced the original bug and verified the fix on a device API level 22. Now I have tried it on API level 21 and I can confirm that it does not work.
The problem is that we are experiencing yet another Android SSLEngine bug. The problem is with SSLEngineResult returned from the SSLEngine#unwrap operation during the handshake. Its method SSLEngineResult#bytesConsumed returns 0 even though it consumed 4K of data from the input buffer. Grizzly has this logic for feeding the input data into the SSL engine:
input.position(position + sslEngineResult.bytesConsumed());

This means that since the position is not moved, the same 4K is fed to the SSLEngine again in the next iteration. SSLEngine of course sees those data as unexpected garbage which results in "routines:SSL3_GET_MESSAGE:unexpected message"

There is nothing we can do about this in Tyrus.
I will ask our colleague maintaing Grizzly if he is willing to put another Android workaround in it. The workaround could calculate the consumed bytes instead of relying on SSLEngineResult#bytesConsumed . Something like:

final ByteBuffer inputByteBuffer = input.toByteBuffer();
int initPosition = inputByteBuffer.position();
... do the unwrap and other stuff
input.position(inPos + inputByteBuffer.position() - initPosition);

I have built my own version of Grizzly with such a patch and it works.

If you want file a bug on Android.

Comment by diwakargoel [ 14/Mar/16 ]

Thanks for looking into this.
I did add a comment to https://java.net/jira/browse/GRIZZLY-1783

Comment by diwakargoel [ 25/Mar/16 ]

https://java.net/jira/browse/GRIZZLY-1827 has been fixed for Grizzly 2.3.25, 3.0.
When is Tyrus 1.12/2.0 expected to be released? Also if you could update the Grizzly dependency.
Thanks!





[TYRUS-419] proxy with basic authentication does not work over ssl. Created: 11/Dec/15  Updated: 17/Feb/16  Resolved: 11/Dec/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: htambekar Assignee: Pavel Bucek
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux, debian.


Issue Links:
Duplicate
duplicates TYRUS-414 Handshake is not effective in case ty... Resolved

 Description   

I am using 'tyrus-standalone-client' version 1.12 and my client is behind squid proxy which is configured with basic authentication.

I can connect through proxy if url starts with "ws:" but I cannot connect over secure connection.

client.getProperties().put(ClientProperties.PROXY_URI, "proxy-url:3128");
      final java.util.HashMap<String, String> proxyHeaders = new java.util.HashMap<String, String>();
      String usernamePassword = "username:" + getPassword();
      proxyHeaders.put("Proxy-Authorization", "Basic " + Base64Utils.encodeToString(usernamePassword.getBytes(Charset.forName("UTF-8")), false));
      client.getProperties().put(ClientProperties.PROXY_HEADERS, proxyHeaders);

      SslContextConfigurator defaultConfig = new SslContextConfigurator();
      System.getProperties().put("javax.net.debug", "all");
      SslEngineConfigurator sslEngineConfigurator = new SslEngineConfigurator(defaultConfig, true, false, false);
      defaultConfig.retrieve(System.getProperties());
      client.getProperties().put(ClientProperties.SSL_ENGINE_CONFIGURATOR, sslEngineConfigurator);

Here is output that I receive

adding as trusted cert:
  Subject: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
  Issuer:  CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
  Algorithm: RSA; Serial number: 0x2e6a000100021fd752212c115c3b
  Valid from Thu Jan 12 09:38:43 EST 2006 until Wed Dec 31 17:59:59 EST 2025

trigger seeding of SecureRandom
done seeding SecureRandom
Using SSLEngineImpl.
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1.1
javax.websocket.DeploymentException: Connection to 'wss://websocket-url' failed.
Error while instantiating WebSocketClient...Connection to 'wss://websocket-url' failed.
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:398)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.access$000(GrizzlyClientSocket.java:103)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:235)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:231)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.connect(GrizzlyClientSocket.java:249)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer.openClientSocket(GrizzlyClientContainer.java:95)
	at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:663)
	at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
	at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
	at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:110)
	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:355)
	at MyWebSocketClient.<init>(MyWebSocketClient.java:56)
	at MyWebSocketClient.main(MyWebSocketClient.java:35)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)


 Comments   
Comment by Pavel Bucek [ 11/Dec/15 ]

Seems like a duplicate of TYRUS-414.

Can you please try with latest 1.13-SNAPSHOT?

Comment by htambekar [ 11/Dec/15 ]

I am sorry, I am little new to this project. Where will I get 1.13-SNAPSHOT? Looks like it is not on maven repo. Also can you tell me how to edit reported issue?

Comment by Pavel Bucek [ 11/Dec/15 ]

No problem

snapshots are available on java.net maven snapshot repository: https://maven.java.net/content/repositories/snapshots.

Only developers/admins can edit an issue - what do you want to change?

Comment by htambekar [ 11/Dec/15 ]

Thank you, I want to replace 'wss://my-private-url-I-did-not-want-to-share' with 'websocket-url'. Its there in couple of places.

Comment by htambekar [ 12/Dec/15 ]

1.13-SNAPSHOT worked for me. thanks. Can you tell me when it will get released?

Comment by diwakargoel [ 17/Feb/16 ]

Yes. What is the expected release date for 1.13? Thanks!





[TYRUS-408] Gradually Increasing Memory Usage with Tyrus Standalone Client 1.11 Created: 31/Aug/15  Updated: 15/Feb/16

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: spstur Assignee: petrjanouch
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tyrus Standalone Client 1.11
Java 8 (-Xmx40M)
Debian Jessie
Tomcat 7


Sprint: Triaged

 Description   

Setup: I have a long running Java 8 service that establishes several persistent websocket connections to a Tomcat 7 websocket server. Messages are sent and received at a fairly slow, consistent rate (3-15 every 15 seconds). The websocket connections disconnect and reconnect about every 10 minutes. I have set the max heap size to 40Mb, just to more efficiently troubleshoot OutOfMemory errors.

Problem: Eventually (after about 2 days), the java process begins throwing `java.lang.OutOfMemoryError: GC overhead limit exceeded`.

Monitoring the rss value of the process via the ps command shows the memory usage of the process increasing gradually (~2k/minute).

Monitoring the memory usage with jstat shows old generation usage increase gradually until it hits the limit. When it does, a full garbage collection happens and cleans up most of it, but each time it leaves a small amount. Eventually it reaches the GC limit threshold and throws the above error.

Analyzing the heap with jmap/jhat, and viewing instance counts shows 4 at the very top (in this order): org.glassfish.grizzly.http.util.BufferChunk, org.glassfish.grizzly.http.util.ByteChunk, org.glassfish.grizzly.http.util.CharChunk, org.glassfish.grizzly.http.util.DataChunk. These instances only get cleaned up when a full garbage collection happens, but each time it leaves some of them.

Viewing the heap histogram shows instances of [B consuming very large amounts (~50%) of the max heap size.

This seems similar to GRIZZLY-84, but that is marked as already fixed.



 Comments   
Comment by Pavel Bucek [ 01/Sep/15 ]

Hi spstur,

thanks for filing this.. interesting issue. Can you please share the code you have for reproducing the issue (minimal reproducer would speed things up greatly). From what you see it could be issue in Grizzly layer, but we can communicate that to them when this is verified.

Also, could you try to use Tyrus JDK client transport? (that does not use Grizzly at all - minimum requirement for this is JDK 7+, which should be ok, since you've indicated that you are using JDK 8).

See https://tyrus.java.net/documentation/1.11/user-guide.html#d0e1331 for more info about using jdk client transport.

Thanks,
Pavel

Comment by spstur [ 03/Sep/15 ]

I switched it over to use the JDK client transport. When analyzing the heap I no longer see any grizzly classes (as you'd expect), but I still see the same problems with memory usage, and now the instance count from the heap shows over 10k instances of class org.glassfish.tyrus.core.coder.CoderWrapper, after running for about 20 hours.

I'm working on a minimal reproducer at the moment, I have a number of other tasks taking precendence but I hope to have that to you in a couple weeks at the most. When I do I'll also try to provide more information about what exactly I'm seeing with the JDK client transport.

Comment by thomascashman [ 24/Sep/15 ]

I have a tyrus websocket client sending 20k messages/second to a tyrus websocket server in another application. I'm experiencing the same pattern of garbage collection and pauses. YourKit showed that the method that's creating the most objects is Async#sendText - can't inspect deeper than that for some reason. The client application dies very quickly - within 1 minute.

However, I've attempted to reproduce this (https://github.com/tomcashman/tyrus-408) in a simple tyrus client/server and it does not die as quickly but can see the old generation slowly increasing.

Comment by petrjanouch [ 15/Feb/16 ]

I have went through a couple of scenarios and I cannot reproduce this. To answer to the comment:

@thomascashman: Thanks for the reproducer. I run it for half an hour, made a heap dump at the beginning and at the and compared the heap dumps (and repeated twice, to be sure). I have rarely seen heap dumps with so little difference. In my view increasing old generation does not mean a memory leak, it might mean that some cached (Grizzly loves caching) and long lived objects get promoted. I am not saying there is not memory leak in your application, just that the reproducer does not reproduce it. You can try the same using jvisualvm (part of JDK). It allows comparing heap dumps.

I have tried my own reproducer, which creates a lot of short lived connections. I have found out the following. I managed to simulate a leak of org.glassfish.grizzly.http.util.BufferChunk, org.glassfish.grizzly.http.util.ByteChunk, org.glassfish.grizzly.http.util.CharChunk, org.glassfish.grizzly.http.util.DataChunk objects if websocket Session is not closed (Either by calling Session#close locally or receiving close frame from the server) or if references to Session are kept after it has been closed. If the Session is closed and references to it not kept around everything seems OK.

I cannot do more without more information. Either the promised reproducer or a heap dump would be helpful.





[TYRUS-416] Hostname variable is not used Created: 27/Nov/15  Updated: 12/Feb/16

Status: Open
Project: tyrus
Component/s: server
Affects Version/s: 1.12
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Christian_Schmidt Assignee: petrjanouch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When using Tyrus in standalone mode the provided hostname in the constructor is not passed to the created container.

-> constructior
new Server(ip, port, "/ws", properties, EndpointCom.class, EndpointData.class);

The container is created in the start() method:
server = ServerContainerFactory.createServerContainer(properties);

for (Class<?> clazz : configuration)

{ server.addEndpoint(clazz); }

server.start(contextPath, port);

And there, the IP/Hostname is not passed to the created Container.






[TYRUS-315] Creating javadoc with JDK8 fails, because of <p/> tags in javadoc. Created: 08/Apr/14  Updated: 12/Feb/16  Resolved: 12/Feb/16

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.5
Fix Version/s: 2.0

Type: Bug Priority: Major
Reporter: petrjanouch Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-421] Missing grizzly server jar from lib? Created: 02/Feb/16  Updated: 12/Feb/16  Resolved: 12/Feb/16

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: andrejbal Assignee: petrjanouch
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I downloaded websocket-ri-archive-1.12.zip, created a standalone example, built it, but trying to run the server I got "java.lang.ClassNotFoundException: org.glassfish.tyrus.container.grizzly.server.GrizzlyServerContainer".
Looking into the jars in the aforementioned zip I found no such class. Could it be that it's missing due to some error during build process on your servers?



 Comments   
Comment by petrjanouch [ 12/Feb/16 ]

Hi,

The RI in websocket-ri-archive stands for a reference implementation (of JSR 356, Java API for Websocket). The JSR is servlet based, so the bundle does not contain GrizzlyServerContainer (which is a Tyrus specific extension) on purpose.

Please refer to this section of the documentation about Tyrus modules, to know which dependencies you need for what: https://tyrus.java.net/documentation/1.12/user-guide.html#modules-and-dependencies





[TYRUS-404] Client hangs if i send recoursively Created: 27/Jul/15  Updated: 25/Jan/16

Status: Reopened
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: goleon Assignee: Pavel Bucek
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Triaged

 Description   

Server side:

@ServerEndpoint("/tests/1client")
public class Tests1Client
{

    @OnOpen
    public void open(Session client) {
        System.out.println("/websocket - open");
    }


    @OnMessage
    public void shout(String text, Session client) throws InterruptedException, IOException
    {
        System.out.println("/websocket -> " + text);
        client.getBasicRemote().sendText(text + "!!!");
    }


    @OnClose
    public void close(Session client) {
        System.out.println("/websocket - close");
    }
}

Case 1: client sends 1000 messages and received 1000 responses. Appeared result is same as expected.
Client with iteration of messages sending:

import javax.websocket.*;
import java.net.URI;
import java.util.concurrent.*;

public class Client1
{
    private static final int MESSAGES_COUNT = 1000;
    public static final String URL = "ws://localhost:8080/jsr356/tests/1client";
    private static final String MESSAGE_50_SYMBOLS = "HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld";

    private long startTime;

    private final CountDownLatch messageLatch = new CountDownLatch(MESSAGES_COUNT);
    private ExecutorService exec;

    public void start()
    {
        try
        {
            exec = Executors.newFixedThreadPool(3);
            startTime = System.currentTimeMillis();

            ClientManager client = ClientManager.createClient();
            client.connectToServer(new Endpoint()
            {
                @Override
                public void onOpen(final Session session, EndpointConfig config)
                {
                    System.out.println("Client connected in time " + ((System.currentTimeMillis() - startTime) / 1000) + "s");

                    session.addMessageHandler(new MessageHandler.Whole<String>()
                    {
                        @Override
                        public void onMessage(String message)
                        {
                            System.out.println(" Client received message " + message);

                            messageLatch.countDown();

                        }
                    });
                    sendMessage(session);
                }

                @Override
                public void onClose(Session session, CloseReason closeReason)
                {
                    System.out.println("Client disconnected");
                }

                @Override
                public void onError(Session session, Throwable thr)
                {
                    System.out.println("Client received error");
                }
            }, ClientEndpointConfig.Builder.create().build(), new URI(URL));
            messageLatch.await();
            if (messageLatch.getCount() != 0)
            {
                System.out.println("Must be sent " + MESSAGES_COUNT + " but send only " + (MESSAGES_COUNT - messageLatch.getCount()));
            }
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }

    private void sendMessage(Session session)
    {
        final RemoteEndpoint.Async async = session.getAsyncRemote();
        for (int i = 0; i < MESSAGES_COUNT; i++)
        {
            final int index = i;
            exec.submit(new Callable<Object>()
            {
                @Override
                public Future<Void> call() throws Exception
                {

                    System.out.println("Try to send message " + " " + index + " " + MESSAGE_50_SYMBOLS);
                    async.sendText(index + " Message " + MESSAGE_50_SYMBOLS);
                    return null;
                }
            });
        }
    }

    public static void main(String[] args)
    {
        new Client1().start();
    }
}

Case 2: client should send message and receive response 1000 times (algorithm is recursive: next message sending client will make in onMessahe handler).
Client with recursive "ping-pong" messages sending:

import org.glassfish.tyrus.client.ClientManager;

import javax.websocket.*;
import java.net.URI;
import java.util.concurrent.*;

public class Client1_recursive
{
    private static final int MESSAGES_COUNT = 1000;
    public static final String URL = "ws://localhost:8080/jsr356/tests/1client";
    private static final String MESSAGE_50_SYMBOLS = "HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld";

    private long startTime;

    private final CountDownLatch messageLatch = new CountDownLatch(MESSAGES_COUNT);
    private ExecutorService exec;

    public void start()
    {
        try
        {
            exec = Executors.newFixedThreadPool(3);
            startTime = System.currentTimeMillis();

            ClientManager client = ClientManager.createClient();
            client.connectToServer(new Endpoint()
            {
                @Override
                public void onOpen(final Session session, EndpointConfig config)
                {
                    System.out.println("Client connected in time " + ((System.currentTimeMillis() - startTime) / 1000) + "s");

                    session.addMessageHandler(new MessageHandler.Whole<String>()
                    {
                        @Override
                        public void onMessage(String message)
                        {
                            System.out.println(" Client received message " + message);

                            messageLatch.countDown();

                            sendMessage(session);
                        }
                    });
                    sendMessage(session);
                }

                @Override
                public void onClose(Session session, CloseReason closeReason)
                {
                    System.out.println("Client disconnected");
                }

                @Override
                public void onError(Session session, Throwable thr)
                {
                    System.out.println("Client received error");
                }
            }, ClientEndpointConfig.Builder.create().build(), new URI(URL));
            messageLatch.await();
            if (messageLatch.getCount() != 0)
            {
                System.out.println("Must be sent " + MESSAGES_COUNT + " but send only " + (MESSAGES_COUNT - messageLatch.getCount()));
            }
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }

    private int i = 0;

    private void sendMessage(Session session)
    {
        final int index = i++;

        final RemoteEndpoint.Async async = session.getAsyncRemote();
        exec.submit(new Callable<Object>()
        {
            @Override
            public Future<Void> call() throws Exception
            {

                System.out.println("Try to send message " + " " + index + " " + MESSAGE_50_SYMBOLS);
                async.sendText(index + " Message " + MESSAGE_50_SYMBOLS);
                return null;
            }
        });
    }

    public static void main(String[] args)
    {
        new Client1_recursive().start();
    }
}

In recursive algorithm about 25 (or 74, or 90...) messages was sent, but client hanged , logs for example may be that:

Try to send message  21 HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld
 Client received message 21 Message HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld!!!
Try to send message  22 HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld
 Client received message 22 Message HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld!!!
Try to send message  23 HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld
 Client received message 23 Message HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld!!!
Try to send message  24 HelloWorldHelloWorldHelloWorldHelloWorldHelloWorld

As seen client sends message 24 ant it must be received on server, but in server logs i see that message is not received on server, and client hanged. Why?



 Comments   
Comment by Pavel Bucek [ 27/Jul/15 ]

This could be a bug but for different reason.

The latter usecase should not work at all - onMessage() method shouldn't be invoked in parallel for the same client. Tyrus should make sure that next onMessage() is not invoked before previous one is finished; we cannot assure in-order message delivery otherwise.

Comment by goleon [ 27/Jul/15 ]

Thanks,
could you explain this restriction please. It is from WebSocket transport or JSR 356 standard or from JSR server side or JSR client side implementation?

Comment by goleon [ 27/Jul/15 ]

And i removed concurrent tasks executor but problem still exists...

Comment by Pavel Bucek [ 27/Jul/15 ]

the "restriction" is from the JSR 356 itself - as I already mentioned, we cannot guarantee in-order message delivery otherwise. Client/Server side does not matter, since they are equal after WebSocket handshake.

I overlooked that you are sending the message from ExecutorService - in that case, it should work; leave it there and to jstack when it "hangs" and post it here, we might be able to find something unusual.





[TYRUS-373] Annotations are not found if bean is proxied (from CDI) Created: 04/Sep/14  Updated: 25/Jan/16  Resolved: 25/Jan/16

Status: Resolved
Project: tyrus
Component/s: client, core, server
Affects Version/s: 1.8.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bruno Borges Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Team Nepenthes

 Description   

Because of issue WEBSOCKET_SPEC-229, implementations such as Tyrus and Undertow cannot find annotations when CDI bean (for @ClientEndpoint for example) is injected as proxied object.

In order for Tyrus and Undertow to support the expected integration of CDI and WebSockets 1.0 or 1.1, the implementation must do recursive scan of annotations, as well invoke methods in a smart way, because reflection won't find @OnMessage/@OnOpen/etc methods in the proxy class.

See this for more details:



 Comments   
Comment by Bruno Borges [ 04/Sep/14 ]

It is also important for JSR 356 implementations to be aware that objects may be CDI proxies and thus any reflection to find annotated methods (say for example @OnMessage) must be carefully implemented.

Comment by Pavel Bucek [ 05/Sep/14 ]

The issue you are experiencing is slightly different than you are describing. Tyrus scans provided class for annotated methods, so @OnOpen (and others) WERE found in your case. Problem is with the invocation part - from the error you posted in the gist, it seems like we should NOT use the method retrieved from original class with proxied object returned from CDI container ( ..?).

To be honest, this seems to me like a bug somewhere else - I don't think we should do anything else what we are doing now - see AnnotatedEndpoint class, concretely callMethod method.

Comment by Bruno Borges [ 05/Sep/14 ]

@ClientEndpoint is not found if the object passed to connectToServer is proxied (from CDI).

Clearly there's a bug in here, and also when calling other annotated methods.

Undertow has this fixed (though not yet tested on my use case) in finding @ClientEndpoint on proxied beans: https://github.com/undertow-io/undertow/commit/4148de5a62d2535d885a81196de7723f14abe9aa





[TYRUS-417] JDK client connector hung when reply to CONNECT not received Created: 30/Nov/15  Updated: 25/Jan/16

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: petrjanouch Assignee: petrjanouch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Team Drosera

 Description   

If a JDK client connector sends a CONNECT to a proxy and for some reason does not receive any reply, it is stuck forever.

There is a test fort this situation (currently ignored). See ProxyTest#testConnectStuck






[TYRUS-406] RETRY_AFTER_SERVICE_UNAVAILABLE flag prevents onDisconnect from setting a delay Created: 21/Aug/15  Updated: 25/Jan/16

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.11
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: enwiner Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you set client.getProperties.put(ClientProperties.RETRY_AFTER_SERVICE_UNAVAILABLE, true) and also set up a ClientProperties.RECONNECT_HANDLER, you hit some strange behavior.

When the connection is closed, the code call the user's ReconnectHandler.onDisconnect() method. If that method returns true, it then calls ReconnectHandler.getDelay() to determine when to reconnect - but that method is overridden by the internal RetryAfterReconnectHandler.getDelay() method, so it will always return 0. I don't see a way to set a user-defined delay for the onDisconnect handler.






[TYRUS-401] Tyrus does not provide enough info when the client endpoint cannot be instantiated. Created: 23/Jul/15  Updated: 25/Jan/16

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.9
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

following code completes without any exception + it can even allow to send a message. Returned session is closed (isOpen() returns false), but there is no information about why that happened.

public class Test {
    public static void main(String[] args) throws IOException, DeploymentException, IllegalAccessException,
            InstantiationException {

        WebSocketContainer client = ContainerProvider.getWebSocketContainer();


        Session s = client.connectToServer(MyEndpoint.class,
                                           URI.create("ws://something.somewhere:someport/somepath"));
        System.out.println("XXX " + s.isOpen());

        System.in.read();
    }

    @ClientEndpoint
    public class MyEndpoint {

        @OnOpen
        public void onOpen(Session session) {
            System.out.println("onOpen " + session.isOpen());
        }
    }
}





[TYRUS-241] l10n - LogLevel INFO+ should be internacionalized. Created: 22/Aug/13  Updated: 25/Jan/16

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Pavel Bucek [ 19/Feb/14 ]

done for tyrus-core





[TYRUS-413] Getting MalformedURLException on reconnecting on network disruption : tyrus-standalone-client Created: 03/Nov/15  Updated: 18/Jan/16  Resolved: 18/Jan/16

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: ramya.v Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 8, JRE 7/8, Client running through JNLP


Sprint: Team Nepenthes

 Description   

We are using tyrus standalone client to connect to a web socket server and receive messages. The client is run from a jnlp.
We use the annotated ClientEndpoint, with an idle timeout of 30 seconds.In case of network disruptions, we attempt to reconnect after 30 seconds of network disruption. However at this point if the network is still down, we get a SecurityException popup with followin stack trace

java.net.MalformedURLException: unknown protocol: ws
	at java.net.URL.<init>(Unknown Source)
	at java.net.URL.<init>(Unknown Source)
	at java.net.URL.<init>(Unknown Source)
	at java.net.URI.toURL(Unknown Source)
	at com.sun.deploy.net.proxy.DeployProxySelector.connectFailed(Unknown Source)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:421)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.access$000(GrizzlyClientSocket.java:103)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:235)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:231)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.connect(GrizzlyClientSocket.java:249)
	at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer.openClientSocket(GrizzlyClientContainer.java:95)
	at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:663)
	at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
	at java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
	at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:317)
	at com.neo.trd.RatesRefresher.init(Unknown Source)
	at com.neo.trd.RatesRefresher.onClose(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:520)
	at org.glassfish.tyrus.core.AnnotatedEndpoint.onClose(AnnotatedEndpoint.java:535)
	at org.glassfish.tyrus.core.AnnotatedEndpoint.onClose(AnnotatedEndpoint.java:544)
	at org.glassfish.tyrus.core.TyrusEndpointWrapper.onClose(TyrusEndpointWrapper.java:1251)
	at org.glassfish.tyrus.core.TyrusWebSocket.onClose(TyrusWebSocket.java:130)
	at org.glassfish.tyrus.core.ProtocolHandler.close(ProtocolHandler.java:469)
	at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:260)
	at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:270)
	at org.glassfish.tyrus.core.TyrusRemoteEndpoint.close(TyrusRemoteEndpoint.java:495)
	at org.glassfish.tyrus.core.TyrusSession.close(TyrusSession.java:233)
	at org.glassfish.tyrus.core.TyrusSession$IdleTimeoutCommand.run(TyrusSession.java:803)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

However we are successfully able to connect using ws. This only happens when there is no network while trying to connect. We do not connect through proxy.



 Comments   
Comment by Pavel Bucek [ 18/Jan/16 ]

Hi,

we don't plan to fix this issue in the near future. If you wan't to get this fixed, please submit a pull request.

Thanks and regards,
Pavel





[TYRUS-399] org.glassfish.tyrus.container.jdk.client.ClientFilter processError Connection error has occurred java.io.IOException Created: 24/May/15  Updated: 04/Jan/16  Resolved: 04/Jan/16

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hugolarson Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows XP
Java 1.7.0_55


Sprint: Team Sarracenia

 Description   

This exception is throws sporadicly in Client Endpoint. The connection is WSS.
The root exception is seem to be thrown from the OS because the message is in Swedish. Have only seen this exception in XP.

2015-05-24 16:56:26:521 [ tyrus-jdk-client-3|]: org.glassfish.tyrus.container.jdk.client.ClientFilter processError Connection error has occurred
java.io.IOException: I/O-åtgärden har avbrutits därför att en tråd har avslutats eller för att ett program har begärt det.

at sun.nio.ch.Iocp.<unknown>(Unknown Source)
at sun.nio.ch.Iocp.access$700(Unknown Source)
at sun.nio.ch.Iocp$EventHandlerTask.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2015-05-24 16:56:29:489 [ tyrus-jdk-client-3|]: java.util.logging.LogManager$RootLogger log tyrus-jdk-client-3
java.nio.channels.WritePendingException
at sun.nio.ch.AsynchronousSocketChannelImpl.write(Unknown Source)
at sun.nio.ch.AsynchronousSocketChannelImpl.write(Unknown Source)
at java.nio.channels.AsynchronousSocketChannel.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.TransportFilter.write(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.SslFilter.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.SslFilter.write(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.TaskQueueFilter$WriteTask.execute(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.TaskQueueFilter.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.TaskQueueFilter.write(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.ClientFilter$JdkWriter.write(Unknown Source)
at org.glassfish.tyrus.core.ProtocolHandler.write(Unknown Source)
at org.glassfish.tyrus.core.ProtocolHandler.<unknown>(Unknown Source)
at org.glassfish.tyrus.core.ProtocolHandler.<unknown>(Unknown Source)
at org.glassfish.tyrus.core.TyrusWebSocket.close(Unknown Source)
at org.glassfish.tyrus.client.TyrusClientEngine$2$1.close(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.ClientFilter.processError(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.Filter.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.Filter.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.Filter.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.Filter.<unknown>(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.failed(Unknown Source)
at org.glassfish.tyrus.container.jdk.client.TransportFilter$4.failed(Unknown Source)
at sun.nio.ch.Invoker.<unknown>(Unknown Source)
at sun.nio.ch.Invoker$2.run(Unknown Source)
at sun.nio.ch.AsynchronousChannelGroupImpl$1.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by Pavel Bucek [ 24/May/15 ]

That (most likely, I don't speak Swedish) means that underlying TCP connection is broken.

We cannot do anything with it - please check server-side settings, you might be hitting some timeout (you can try to set hearth beat interval: https://tyrus.java.net/apidocs/1.10/org/glassfish/tyrus/core/TyrusSession.html#setHeartbeatInterval(long) ) .. other than that .. it's really hard to say. You would need to have access to server-side logs, there could be something more usable.

I'll set the issue to "incomplete" state - feel free to reopen with more details (or just add comment, if you are not able to reopen - I'll do that).

Thanks and regards,
Pavel

Comment by hugolarson [ 25/May/15 ]

Hello,
There is nothing on the server side
On the server side I check if session.isopen before sending to client.
Should Tyrus crash this hard when this happens? Looks like a RuntimeException is thrown from Tyrus thread which crashes my entire client application.
I'm using ReconnectHandler.

BR,

Comment by Pavel Bucek [ 25/May/15 ]

After short consult with Petr (main JDK Client contributor), I'm reopening this issue.

This exception indicates that the write was called on a socket which has another write "command" pending. That should not happen, but it might be possible that socket instance is leaked and shared among client instances when reconnect handler is used or .. there might be some concurrency issue in Tyrus code.. we will need to check that out.

Any reproducer would greatly help in further evaluation.

Thanks,
Pavel

Comment by hugolarson [ 25/May/15 ]

I have been using Tyrus in development environment (Windows 8.1) for weeks now without seeing this show stopper even once.
It's now in production environment on windows XP that I see this very often.
XP is still widely used in Point Of Sale computers. It's still supported and is called Windows POSREADY 2009.

Don't have any other clue. Should I not use ReconnectHandler? Any other workaround suggestion is appreciated.

I can run a debug build of Tyrus in my environment to help you debug if you want.

BR,
Hugo

Comment by hugolarson [ 25/May/15 ]

Another Exception

2015-05-24 17:27:36:640 [ tyrus-jdk-client-4|]: org.glassfish.tyrus.container.jd
k.client.ClientFilter processError Connection error has occurred
java.io.IOException: The I/O operation has been aborted because of either a thre
ad exit or an application request.

at sun.nio.ch.Iocp.<unknown>(Unknown Source)
at sun.nio.ch.Iocp.access$700(Unknown Source)
at sun.nio.ch.Iocp$EventHandlerTask.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Comment by Pavel Bucek [ 25/May/15 ]

You could try not to use ReconnectHandler.. or try with JDK 8 on Windows XP, since it might be related to platform internal implementation..

Comment by hugolarson [ 25/May/15 ]

Removed ReconnectHandler. Still same problem.

Comment by hugolarson [ 27/May/15 ]

Another theory.
We have only seen this exception on slow computers, which is common in the POS business. With slow I mean embedded 1.5 GHz CPU.
It makes sense that concurrency problem is much observable on slow computers.

Comment by Pavel Bucek [ 27/May/15 ]

Have you tried JDK 8?

Comment by Pavel Bucek [ 27/May/15 ]

BTW, Peter has "good news" for you - he was able to reproduce your issue on Win XP virtual box. Nevertheless, it seems like WinXP might have more issues than this one - we will keep this post updated. Unfortunately, this platform is not our priority and since it does not seem to be reproducible (or at least we haven't seen this anywhere else yet), so the fix might take couple of weeks or more..

Comment by hugolarson [ 28/May/15 ]

Astonishing that Java code runs fine on one version of Windows and not on other!
We have our software on over 400 sites, updating to Jre 8 is not an option, hence I have not tried.

I tried Jetty implementation and it does not suffer from same problem but I prefer Tyrus because it has nice features such as ReconnectHandler.

I understand that you are committing to fix this problem in XP but it will take some weeks?
Please keep us posted if you change your mind on making Tyrus compatible with XP.

Comment by Pavel Bucek [ 28/May/15 ]

yeah, "write once run anywhere" does not work for all cases..

BTW, you don't need to switch to different client vendor, you can just use Grizzly based implementation, since this bug seem to be scoped to JDK transport, see https://tyrus.java.net/dependencies.html, concretely

<dependency>
    <groupId>org.glassfish.tyrus.bundles</groupId>
    <artifactId>tyrus-standalone-client</artifactId>
    <version>1.10</version>
</dependency>

When you do that, you'll switch to different client container implementation, but all APIs are still the same, so you should not need to change single line in your code and all features will work as they used to.

Grizzly client transport is slightly larger (in terms of jar size) but runs on Java 1,6+. JDK client transport is really small, but it requires Java 1.7+ (and apparently has this XP compatibility bug..)

Anyway, we are still looking into that, but as I mentioned last time, it could take a while, but you can still use Tyrus client with Grizzly transport.

Comment by hugolarson [ 28/May/15 ]

"Slightly" is 4 times larger in jar size
Will go ahead and try out Grizzly.

Comment by Libor Kramolis [ 04/Jan/16 ]

Please try out the Grizzly connector as Pavel mentioned.

In case you feel strongly about the issue, please consider contributing a fix by submitting a Github pull request.





[TYRUS-364] @PostConstruct and @PreDestroy of a @ServerEndpoint is not called Created: 22/Aug/14  Updated: 04/Jan/16  Resolved: 04/Jan/16

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: martinandersson.com Assignee: Pavel Bucek
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Windows 8 x64, GlassFish 4.0.1-b08-m1



 Description   

WebSocket specification (JSR-356), section 7.1.1 says:

"Websocket implementations part of the Java EE platform are required to
support [..] the use of interceptors for these classes. The details of this requirement are laid out in the Java EE Platform Specification, section EE.5.2.5."

The Java EE Platform Specification section EE.5.2.5 says:

"The component classes listed in Table EE.5-1with support level 'Standard' all support Java EE resource injection, as well as PostConstruct and PreDestroy callbacks."

According to table EE.5-1 in the Java EE Platform specification, WebSocket has standard support level.

For me, it is a most wanted feature to a have a @PreDestroy callback since I must programmatically destroy @Dependent beans that I have injected into my server endpoint. For now, that code will be put in the @OnClose callback instead.



 Comments   
Comment by Pavel Bucek [ 22/Aug/14 ]

Hi Martin,

thanks for the report! Can you please re-test with latest 4.1 build [1]?

Regards,
Pavel

[1] http://dlc.sun.com.edgesuite.net/glassfish/4.1/promoted/glassfish-4.1-b13.zip

Comment by martinandersson.com [ 22/Aug/14 ]

Failed to setup my application with GlassFish 4.1-b13 properly. Might take a while before I have the chance to look again!

Noteworthy: I moved my "CDI.current().destroy()" call to the @OnClose method but that crashed with an exception complaining about current running thread not being associated with a context (not ContextNotActiveException!). Funny thing, because I managed to get hold of the @Dependent bean using "CDI.current().select()" during @OnOpen. I'll have to skip this CDI thing altogether.

Comment by Pavel Bucek [ 22/Aug/14 ]

You are hitting https://java.net/jira/browse/WEBSOCKET_SPEC-197

@OnOpen is called during handshake phase, so container still considers that as a request scope. Other than that, the behaviour is undefined :-/. You can also inject when the endpoint is created (falls into the same category), but @OnMessage, @OnError and @OnClose are problematic. Unfortunately, this cannot be easily fixed in Tyrus, since we do rely on the environment passed down from Servlet here.

Comment by Pavel Bucek [ 04/Jan/16 ]

closing as incomplete - feel free to comment / reopen.





[TYRUS-420] TyrusServletContainerInitializer#onStartup() not compatible with container-provided endpoints Created: 18/Dec/15  Updated: 18/Dec/15  Resolved: 18/Dec/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: balusc Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For JSF 2.3 / Mojarra I'm currently in progress of adding a standard <f:socket> tag. As Mojarra is to be designed as a container-provided JAR (not an user-provided JAR), the endpoint needs to be programmatically added in a ServletContextListener, but at that point, servletContext.getAttribute(ServerContainer.class.getName()) returns null when Tyrus is used (Payara/GlassFish). Upon inspection it turns out that the TyrusServletContainerInitializer#onStartup() immediately returns when there are no user-provided endpoints and doesn't register the ServerContainer anymore, causing it to not be placed in ServletContext anymore.

I'm not seeing anywhere in the JSR356 spec chapter 6.4 that this behavior is mandated.



 Comments   
Comment by Pavel Bucek [ 18/Dec/15 ]

It is not even mandated to work in a way you'd like.

If we won't do this check, then TyrusServletFilter will be registered to ALL deployed applications, which is not desired.

I'm open to any suggestions, (feel free to add comments), but for now, I see this as "works as designed".

Comment by balusc [ 18/Dec/15 ]

If that's even not covered by the spec, what's in your opinion the correct way to provide a websocket from a container JAR on? By the way, programmatic registration this way doesn't cause trouble in a.o. Tomcat and Undertow. Undertow even allows registering it during runtime long after startup, on the contrary to the spec. As to the TyrusServletFilter, I checked its source and find its overhead is really negligible.

In JSF 2.3 / Mojarra side, the socket endpoint is also not by default enabled. It's enforced by a context parameter whose name is still undefined, but shall probably be like "javax.faces.ENABLE_SOCKET_ENDPOINT". If this is present, then Mojarra will register its socket endpoint. You could consider checking for the same context param before skipping the ServerContainer registration. Although this approach is kind of hacky as it tight-couples WS API with JSF API.

A more clean solution would be to let the spec explicitly define the desired behavior, along with the possibility to enforce WS container initialization based on some specific context attribute (e.g. key ServerContainer.class.getName() is present, but value is null; JSF could just set that beforehand in its container initializer).

As last resort, reflection could be used to manually re-trigger TyrusServletContainerInitializer#onStartup() from JSF's container initializer, passing the desired endpoint class. But, also too hacky.





[TYRUS-414] Handshake is not effective in case tyrus client connects through http proxy to standalone tyrus server which is down Created: 20/Nov/15  Updated: 11/Dec/15  Resolved: 30/Nov/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.12
Fix Version/s: 1.13, 2.0

Type: Bug Priority: Major
Reporter: genadir Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

client/server on windows through apache 2.4.17 configured to support websocket and with authentication


Issue Links:
Duplicate
is duplicated by TYRUS-419 proxy with basic authentication does ... Resolved
Sprint: Triaged

 Description   

In case standalone tyrus server (i am trying to connect through apache http proxy) is down then:

  • if i use jdk client then connectToServer method stuck. I can see in console two lines (see below) and nothing happens - application stuck and timeout not effected here.
    17, 2015 8:14:31 AM org.glassfish.tyrus.container.jdk.client.ClientFilter processRead
                           EVERE: Could not connect to proxy: 502
  • If i use grizzly client then after some timeout i get error and application finished - this is ok
    javax.websocket.DeploymentException: Handshake response not received.
                   at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:694)
                  at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
                  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
                  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
                  at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
                  at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
                  at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
                  at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:317)
                  at ws.client.WebSocketClient.main(WebSocketClient.java:155)

    Failed to connect to server with error:Handshake response not received.
    Closing client

In case server is up (behind the proxy) everything is working correct.
I have already configured

client.getProperties().put(ClientProperties.HANDSHAKE_TIMEOUT, DEFAULT_HANDSHAKE_TIMEOUT);

and it seems working good for grizzly client.
It seems like when we try to connect to server through proxy timeout is not working.






[TYRUS-374] Websocket engine is invoked on Grizzly even if the application and request context root do not match Created: 09/Sep/14  Updated: 30/Nov/15  Resolved: 30/Nov/15

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: 1.8.2
Fix Version/s: 1.12

Type: Bug Priority: Major
Reporter: petrjanouch Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-415] Async connect can not be canceled Created: 21/Nov/15  Updated: 23/Nov/15

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.12
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hoschott Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: deferred
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

TyrusFuture does not fulfill java.util.concurrent.Future contract in a useful manner.

The methods cancel(boolean) and isCancelled() are not implemented. Thus this implementation of Future works more like a Promise known from other languages.






[TYRUS-196] Implement correct @PreDestroy calling for user provided ServerEndpointConfig.Configurator Created: 17/Jun/13  Updated: 23/Nov/15

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: stepan.kopriva Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: deferred
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on WEBSOCKET_SPEC-207 ServerEndpointConfig$Configurator get... Open

 Description   

Change in API needed to be able to resolve the task, see WEBSOCKET_SPEC-207






[TYRUS-306] java.lang.IllegalStateException: Already set read listener Created: 14/Mar/14  Updated: 23/Nov/15  Resolved: 23/Nov/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.4, 1.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: mreichman Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64-bit, JDK 1.7.0_25, Glassfish 4.0.1b4


Issue Links:
Blocks
is blocked by GLASSFISH-21007 HTTP Upgrade handler init called twic... In Progress
Dependency
depends on GLASSFISH-21007 HTTP Upgrade handler init called twic... In Progress

 Description   

Upon websocket connections from a remote client, I am getting a scenario where the TyrusHttpUpgradeHandler init method is being called twice, and causing two calls to OnOpen, and the following trace in glassfish server.log

[2014-03-14T11:23:26.604-0400] [glassfish 4.0] [WARNING] [] [org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606604] [levelValue: 900] [[
  Already set read listener
java.lang.IllegalStateException: Already set read listener
	at org.apache.catalina.connector.InputBuffer.setReadListener(InputBuffer.java:303)
	at org.apache.catalina.connector.CoyoteInputStream.setReadListener(CoyoteInputStream.java:312)
	at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.init(TyrusHttpUpgradeHandler.java:105)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:777)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:412)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
	at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:215)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:291)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:209)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:137)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:115)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:550)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
	at java.lang.Thread.run(Thread.java:724)
]]

I set glassfish logging on org.glassfish.tyrus to FINEST, and have the following context immediately before the trace:

[2014-03-14T11:23:26.558-0400] [glassfish 4.0] [FINE] [] [org.glassfish.tyrus.servlet.TyrusServletFilter] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606558] [levelValue: 500] [CLASSNAME: org.glassfish.tyrus.servlet.TyrusServletFilter] [METHODNAME: doFilter] [[
  Setting up WebSocket protocol handler]]

[2014-03-14T11:23:26.558-0400] [glassfish 4.0] [FINE] [] [org.glassfish.tyrus.servlet.TyrusServletFilter] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606558] [levelValue: 500] [CLASSNAME: org.glassfish.tyrus.servlet.TyrusServletFilter] [METHODNAME: doFilter] [[
  Upgrading Servlet request]]

[2014-03-14T11:23:26.558-0400] [glassfish 4.0] [FINE] [] [org.glassfish.tyrus.servlet.TyrusServletFilter] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606558] [levelValue: 500] [CLASSNAME: org.glassfish.tyrus.servlet.TyrusServletFilter] [METHODNAME: doFilter] [[
  Handshake Complete]]

[2014-03-14T11:23:26.589-0400] [glassfish 4.0] [CONFIG] [] [org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606589] [levelValue: 700] [[
  Servlet 3.1 Upgrade]]

[2014-03-14T11:23:26.604-0400] [glassfish 4.0] [FINEST] [] [org.glassfish.tyrus.servlet.TyrusServletWriter] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606604] [levelValue: 300] [CLASSNAME: org.glassfish.tyrus.servlet.TyrusServletWriter] [METHODNAME: onWritePossible] [[
  OnWritePossible called]]

[2014-03-14T11:23:26.604-0400] [glassfish 4.0] [CONFIG] [] [org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler] [tid: _ThreadID=28 _ThreadName=http-listener-1(3)] [timeMillis: 1394810606604] [levelValue: 700] [[
  Servlet 3.1 Upgrade]]

This is inconsistent between different hosts, but consistent on the hosts it occurs with. The OnOpen method will be called twice, two sessions are made, etc., which leads to a difficult management situation. On the hosts where this doesn't occur, everything behaves properly. This seems to have been introduced when moving from Glassfish 4.0.1b3 to 4.0.1b4. I've tried manually dropping in the 1.5 tyrus jars, clearing osgi cache and generated, and it still happens with that version.

My endpoint, which runs under EE role security. It can be made not to by removing references to the principal:

EchoEndpoint.java
@ServerEndpoint("/socket/echo")
public class EchoEndpoint {
    private static final Set<Session> connectedSessions = Collections.synchronizedSet(new HashSet<Session>());

    private void sendAll(String message, Session originator) throws IOException {
        StringBuilder fullMessage = new StringBuilder(message);
        fullMessage.append(" (SESSION: ").append(originator.getId()).append(") ");
        fullMessage.append(" (USER:").append(originator.getUserPrincipal().getName()).append(") ");

        for (Session session : connectedSessions) {
            session.getBasicRemote().sendText(fullMessage.toString());
        }
    }

    @OnOpen
    public void onOpen(Session session) throws IOException {
        connectedSessions.add(session);
        sendAll("session opened, count: " + connectedSessions.size(), session);
    }

    @OnMessage
    public void echoToAll(String message, Session session) throws IOException{
        sendAll(message, session);
    }

    @OnClose
    public void onClose(Session session) throws IOException {
        connectedSessions.remove(session);
        sendAll("session closed, count: " + connectedSessions.size(), session);
    }

    @OnError
    public void onError(Session session, Throwable t) throws IOException {
        sendAll("ERROR: " + t.getMessage(), session);
    }



 Comments   
Comment by Pavel Bucek [ 14/Mar/14 ]

thanks for your report. Do you have some other setup which would require successful reproduction of this issue? Is your server under (heavy) load or something like that? Does that happen often or just once per 1k requests or ... ?

and BTW, Session has getOpenSessions method, so you don't need to store open sessions in a set (private static final Set<Session> connectedSessions).

Comment by Pavel Bucek [ 14/Mar/14 ]

anyway, I forgot to mention - this looks like servlet implementation issue :-/ "Servlet 3.1 Upgrade" log message is printed out from the into method from HttpUpgradeHandler implementation which is controlled by Servlet API.

Which client do you used for accessing your application? javascript or something else? Can you share the code?

Thanks!

Comment by mreichman [ 14/Mar/14 ]

I have a setup which can reproduce this. I don't know what's special about it, no load, every request:
any client -> this server, it happens
my client -> localhost, doesn't happen
client on that server -> my server, doesn't happen

I agree that it smells like an issue somewhere else in glassfish, how do I proceed to get enough info/evidence together and where would I post a ticket? I'm not sure how that works exactly..

Client in JS in a browser, nothing funny, just direct use of the websocket api.

I got that code from a sample a long time ago, before I was as familiar. This was just an example to see it still happen, it's been happening in my application in a more complex endpoint.

Comment by Pavel Bucek [ 14/Mar/14 ]

I'll try to investigate and then we can cooperate and file issue against GF ..

.. just one last try - are you able to reproduce this on different JDK? Lets say 1.7_u51? And can you please share the link from where you downloaded glassfish? (just to be sure we are testing same version)

Comment by mreichman [ 14/Mar/14 ]

I will try u51.
Glassfish was here:
http://dlc.sun.com.edgesuite.net/glassfish/4.0.1/promoted/glassfish-4.0.1-web-b04-ml.zip

This is difficult because I can only seem to see it happen on this one server.

EDIT: Tried u51, no difference.

Comment by mreichman [ 14/Mar/14 ]

Client code, sorry!

<html>
<head>
    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
    <meta charset="utf-8">
    <title>Web Socket JavaScript Echo Client</title>
</head>

<body>

<script language="javascript" type="text/javascript">
    var wsUri = "ws://" + window.location.host + "/socket/echo";

    function init() {
        output = document.getElementById("output");
    }

    function doOpen() {
        websocket = new WebSocket(wsUri);
        websocket.onopen = function (evt) {
            onOpen(evt)
        };
        websocket.onmessage = function (evt) {
            onMessage(evt)
        };
        websocket.onerror = function (evt) {
            onError(evt)
        };
        websocket.onclose = function(evt) {
            onClose(evt);
        }
    }

    function doClose() {
        websocket.close();
    }

    function doSend() {
        websocket.send(document.forms[0].textID.value);
        writeToScreen("SENT: " + document.forms[0].textID.value);
    }

    function writeToScreen(message) {
        var pre = document.createElement("p");
        pre.style.wordWrap = "break-word";
        pre.innerHTML = message;
        //alert(output);
        output.appendChild(pre);
    }

    function onOpen(evt) {
        writeToScreen("CONNECTED");
    }

    function onMessage(evt) {
        writeToScreen("RECEIVED: " + evt.data);
    }

    function onClose(evt) {
        writeToScreen("CLOSED");
    }

    function onError(evt) {
        writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data);
    }



    window.addEventListener("load", init, false);

</script>

<h2 style="text-align: center;">Web Socket Echo Client</h2>

<div style="text-align: center;"><img style=" width: 64px; height: 64px;" alt="" src="resources/img/HTML5_Logo_512.png"></div>
<br>

<div style="text-align: center;">
    <form action="">
        <input onclick="doOpen()" value="Open" type="button">
        <input onclick="doSend()" value="Press me" type="button">
        <input onclick="doClose()" value="Close" type="button">
        <label for="textID">Message</label><input id="textID" name="textID" value="Hello Web Sockets !" type="text"><br>
    </form>
</div>
<div id="output"></div>
</body>
</html>
Comment by mreichman [ 14/Mar/14 ]

Another update:
I tried the latest nightly:
http://dlc.sun.com.edgesuite.net/glassfish/4.0.1/nightly/glassfish-4.0.1-b04-03_13_2014-ml.zip

Still had the same issue. It seems like it came up between the b03 promoted and b04 promoted, and since it's only on the one machine I'm suspect that it's a real issue at all, vs. something on the machine's networking, etc. However, it does happen on the machine itself going to localhost, so I don't know what to think.

Glad for your assistance on the glassfish side, I'm out of testing ideas for now.

Comment by Pavel Bucek [ 17/Mar/14 ]

I tried to reproduce this issue and I was not successful in that task, which is not very surprising given the issue description..

.. well, I know you did a lot of work on that, but isn't there something on that particular machine which is different compared to others? Do you have some similar one and have you tried to reproduce the issue there as well?

I tested latest GF build on Mac OS, Linux (3.2) and Windows 7 (64b) and nothing seem to produce same exception or state.

Please don't take this as me not recognising this as an issue - I just need some more information to be able to narrow down this issue as possible.

Thanks!

Comment by mreichman [ 17/Mar/14 ]

I appreciate the test attempts; I understand this is hard to diagnose. I will see if I can identify anything special about the machine in question. I have routed around the issue in my production code, but I haven't been able to reproduce it anywhere else either.

If I get some more information I will post it here.

Comment by mreichman [ 17/Mar/14 ]

Found it!

When glassfish access logging is turned on, it seems to happen every time.

You should be able reproduce this, in glassfish administration, go to server-config, HTTP service, and turn on Access Logging. Resubmit the test and it should make this happen.

Comment by Pavel Bucek [ 17/Mar/14 ]

wow. great work, thanks!

I was able to reproduce the issue on my mac, so it is not platform dependent.

Comment by mreichman [ 17/Mar/14 ]

GLASSFISH-21007 filed. Do we leave this open until it's fixed on their side and we can confirm this goes away?

Comment by Pavel Bucek [ 17/Mar/14 ]

Yes, thanks!

Comment by Instrumentalityy [ 30/Sep/15 ]

Has any progress been made regarding this issue?
The same is happening in glassfish 4.1 build 13.
Both Access Logging and SSO are disabled.
Thanks

Comment by Pavel Bucek [ 01/Oct/15 ]

Hi Instrumentalityy,

sorry, I'm not aware of any progress. I know there was one attempt to fix this, but it broke more things than it fixed, so we reverted it. I suggest asking on GLASSFISH-21007 (which you already did).

Technically, I should close this one (I might do it), since this does not seem like something we can fix in Tyrus workspace.

Regards,
Pavel

Comment by Instrumentalityy [ 01/Oct/15 ]

Hi, thanks for the response.
We corrected the problem by removing a property "redirect_1" that we had just added in /server-config/Virtual Servers/server/ as described in https://java.net/jira/browse/GLASSFISH-21115 .
That solved the problem for us.

Thanks again, regards,

Comment by Pavel Bucek [ 23/Nov/15 ]

Closing this issue, the state of the bug is tracked in GLASSFISH-21007.





[TYRUS-412] NPE when ProxySelector.getDefault() returns NULL Created: 25/Sep/15  Updated: 07/Oct/15  Resolved: 07/Oct/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.12
Fix Version/s: 1.13, 2.0

Type: Bug Priority: Major
Reporter: hoschott Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Max OS X 10.10, JDK 1.7


Sprint: Scheduled

 Description   

When setting `ProxySelector.setDefault(null)` both `GrizzlyClientSocket.processProxy(...)` and `JdkClientContainer.processProxy(...) throw an NullPointerException.

Unsetting the system wide proxy selector by setting it to null is explicitly allowed.



 Comments   
Comment by Pavel Bucek [ 07/Oct/15 ]

fixed in the master and 1.x branches.

Thanks for the report!





[TYRUS-410] WebSocket as Java EE component but JAAS not include Created: 13/Sep/15  Updated: 22/Sep/15

Status: Open
Project: tyrus
Component/s: server
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: hhf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: deferred
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish server


Issue Links:
Blocks
is blocked by WEBSOCKET_SPEC-197 Better define integration with EJB an... Open

 Description   

Websocket is part of Java EE 7 but I can't apply Jaas mecanism from bean called from websocket

I secure web application with basic auth, and define roles and group/role mapping.
Everythings works fine with Servlet.

Now with websocket
From the method onMessage,
we can check user from session argument ok

@OnMessage
public void receiveCommandMessage(Session client, String msg) {
    session.getUserPrincipal()
}

We can too check role from configurator

@ServerEndpoint(value = "/endpoint", configurator = MyConfigurator.class)
public class MyEndpoint {
public class MyConfigurator extends ServerEndpointConfig.Configurator {
	@Override
	public void modifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response) {
		request.isUserInRole(ROLE);
	}
}

Endpoint is java EE component but when I inject CDI Bean inside, JAAS Context is not initialized, samething for EJB

In CDI Bean the injection of Principal return an ANONYMOUS Princiapl
In EJB injection of SessionContext is not initialized
JAAS Annotations @DeclaredRole and RoleAllowed etc... of course block all call.

I understand that the Endpoint is as an Singleton. But is there a solution ?
How I can do ?
an idea ?
there is bug ?






[TYRUS-392] Unable to use Tyrus 1.9 in android 4.4.2 appllication Created: 02/Jan/15  Updated: 16/Sep/15  Resolved: 16/Sep/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.9
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: hsamu Assignee: Pavel Bucek
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

kitkat 4.4.2



 Description   

Java code uses javax.websocket API:

import javax.websocket.WebSocketContainer;
WebSocketContainer websocket_container = ContainerProvider.getWebSocketContainer();

I tried building with both Java 1.6 and 1.7, and get the same result. It worked in an emulator on linux with Java 1.7...

12-31 15:29:27.144 17162-17162/com.xxx.pushservice I/dalvikvm﹕ Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1719 'Lorg/osgi/framework/SynchronousBundleListener;'
12-31 15:29:27.144 17162-17162/com.xxx.pushservice W/dalvikvm﹕ Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
12-31 15:29:27.144 17162-17162/com.xxx.pushservice I/dalvikvm﹕ Could not find method org.glassfish.tyrus.core.OsgiRegistry.getInstance, referenced from method org.glassfish.tyrus.core.ReflectionHelper.getOsgiRegistryInstance
12-31 15:29:27.144 17162-17162/com.xxx.pushservice W/dalvikvm﹕ VFY: unable to resolve static method 11655: Lorg/glassfish/tyrus/core/OsgiRegistry;.getInstance ()Lorg/glassfish/tyrus/core/OsgiRegistry;
12-31 15:29:27.145 17162-17162/com.xxx.pushservice I/dalvikvm﹕ Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1719 'Lorg/osgi/framework/SynchronousBundleListener;'
12-31 15:29:27.145 17162-17162/com.xxx.pushservice W/dalvikvm﹕ Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
12-31 15:29:27.145 17162-17162/com.leapfrog.pushservice W/dalvikvm﹕ VFY: unable to find class referenced in signature (Lorg/glassfish/tyrus/core/OsgiRegistry
12-31 15:29:27.163 17162-17162/com.xxx.pushservice W/dalvikvm﹕ threadid=1: thread exiting with uncaught exception (group=0x41a28ce0)
12-31 15:29:27.163 17162-17162/com.xxx.pushservice W/dalvikvm﹕ threadid=1: uncaught exception occurred
12-31 15:29:27.163 17162-17162/com.xxx.pushservice W/System.err﹕ java.lang.RuntimeException: Unable to instantiate service com.xxx.services.PusherService: java.lang.NullPointerException



 Comments   
Comment by hsamu [ 02/Jan/15 ]

similar to https://java.net/jira/browse/TYRUS-387

Comment by Pavel Bucek [ 06/Jan/15 ]

this message can be safely ignored - the client runtime works even after this is logged.

decreasing priority.





[TYRUS-405] GrizzlyClientSocket has extra String.format() Created: 11/Aug/15  Updated: 16/Sep/15  Resolved: 16/Sep/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 1.12

Type: Bug Priority: Minor
Reporter: md1084 Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In GrizzlyClientSocket.processProxy() its doing the following:

LOGGER.log(Level.FINE, String.format(String.format("Not using proxy for URI '%s'.", uri)));

The 2nd String.format() causes issues if there is a character such as ':' in the uri (which is escaped to "%3A") and causes String.format to throw a MissingFormatArgumentException. This causes the connection to never succeed.



 Comments   
Comment by Pavel Bucek [ 16/Sep/15 ]

fixed in master branch. Thanks!





[TYRUS-407] java.lang.RuntimeException: Thread's context class loader is null Created: 25/Aug/15  Updated: 16/Sep/15  Resolved: 16/Sep/15

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: 1.10
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Swiss_Codeaholic Assignee: Pavel Bucek
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.1/ java EE7



 Description   

I would like to reference to my stackoverflow question where i described the problem: http://stackoverflow.com/questions/32197106/websocket-runtime-exception

java.lang.RuntimeException: Thread's context class loader is null
at org.glassfish.weld.ACLSingletonProvider$ACLSingleton.getClassLoader(ACLSingletonProvider.java:147)
at org.glassfish.weld.ACLSingletonProvider$ACLSingleton.get(ACLSingletonProvider.java:108)
at org.jboss.weld.Container.instance(Container.java:65)
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:75)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78)
at com.ceyeclon.admin.business.websockets.HWGatewaySessionHandler$Proxy$_$$_WeldClientProxy.removeSession(Unknown Source)
at com.ceyeclon.admin.business.websockets.HWGatewayWebSocketServer.close(HWGatewayWebSocketServer.java:47)
at sun.reflect.GeneratedMethodAccessor1368.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:477)
at org.glassfish.tyrus.core.AnnotatedEndpoint.onClose(AnnotatedEndpoint.java:492)
at org.glassfish.tyrus.core.AnnotatedEndpoint.onClose(AnnotatedEndpoint.java:501)
at org.glassfish.tyrus.core.TyrusEndpointWrapper.onClose(TyrusEndpointWrapper.java:1120)
at org.glassfish.tyrus.core.TyrusWebSocket.onClose(TyrusWebSocket.java:121)
at org.glassfish.tyrus.core.ProtocolHandler.close(ProtocolHandler.java:299)
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:249)
at org.glassfish.tyrus.core.TyrusWebSocketEngine$TyrusConnection.close(TyrusWebSocketEngine.java:650)
at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.close(TyrusHttpUpgradeHandler.java:288)
at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.onError(TyrusHttpUpgradeHandler.java:231)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.processError(InputBuffer.java:614)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.onError(InputBuffer.java:575)
at org.glassfish.grizzly.http.io.InputBuffer.terminate(InputBuffer.java:1028)
at org.glassfish.grizzly.http.server.Response$SuspendedContextImpl.markCancelled(Response.java:2031)
at org.glassfish.grizzly.http.server.Response$SuspendedContextImpl$SuspendCloseListener.onClosed(Response.java:2108)
at org.glassfish.grizzly.http.server.Response$SuspendedContextImpl$SuspendCloseListener.onClosed(Response.java:2096)
at org.glassfish.grizzly.nio.NIOConnection.invokeCloseListener(NIOConnection.java:928)
at org.glassfish.grizzly.nio.NIOConnection.notifyCloseListeners(NIOConnection.java:817)
at org.glassfish.grizzly.nio.NIOConnection.terminate0(NIOConnection.java:550)
at org.glassfish.grizzly.nio.transport.TCPNIOConnection.terminate0(TCPNIOConnection.java:292)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.read(TCPNIOTransport.java:654)
at org.glassfish.grizzly.nio.transport.TCPNIOTransportFilter.handleRead(TCPNIOTransportFilter.java:75)
at org.glassfish.grizzly.filterchain.TransportFilter.handleRead(TransportFilter.java:173)
at org.glassfish.grizzly.ssl.SSLBaseFilter$SSLTransportFilterWrapper.handleRead(SSLBaseFilter.java:999)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:132)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:111)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:745)



 Comments   
Comment by Pavel Bucek [ 16/Sep/15 ]

stackoverflow question was removed; feel free to reopen with more info





[TYRUS-354] Invalid Connection header value: "Keep-Alive" Created: 30/Jul/14  Updated: 16/Sep/15  Resolved: 16/Sep/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.7
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dungld Assignee: Pavel Bucek
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian 7.5 64bit, Glassfish 4.0.1 b8, JDK 7 update 51


Issue Links:
Duplicate
is duplicated by TYRUS-352 Invalid Connection header value: "Kee... Resolved
is duplicated by TYRUS-353 Invalid Connection header value: "Kee... Resolved

 Description   

When I run Glassfish 4.0.1 b08, it throws exception to log:

[2014-07-30T09:14:03.709+0700] [glassfish 4.0] [SEVERE] [] [websocket] [tid: _ThreadID=1026 _ThreadName=http-listener-1(1001)] [timeMillis: 1406686443709] [levelValue: 1000] [[
Invalid Connection header value: "Keep-Alive".
org.glassfish.tyrus.core.HandshakeException: Invalid Connection header value: "Keep-Alive".
at org.glassfish.tyrus.core.Handshake.validate(Handshake.java:268)
at org.glassfish.tyrus.core.Handshake.checkForHeader(Handshake.java:260)
at org.glassfish.tyrus.core.Handshake.createServerHandshake(Handshake.java:220)
at org.glassfish.tyrus.core.ProtocolHandler.handshake(ProtocolHandler.java:142)
at org.glassfish.tyrus.core.TyrusWebSocketEngine.upgrade(TyrusWebSocketEngine.java:309)
at org.glassfish.tyrus.servlet.TyrusServletFilter.doFilter(TyrusServletFilter.java:241)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)
]]



 Comments   
Comment by Pavel Bucek [ 30/Jul/14 ]

Can you share more info about the usecase? Which client do you use? (is it browser?).

Comment by dungld [ 30/Jul/14 ]

I use Firefox, but I can not sure about my client browser which they use, because this web has been published over internet. I can provide log to you only.

Comment by Pavel Bucek [ 30/Jul/14 ]

Seems like some of your client tries to connect with incorrect Connection header value - "Keep-Alive".

Tyrus accepts anything which contains the word "upgrade" (case insensitive). The request which caused this does not seem to contain this particular value. Can you please verify and share the details? Ideally with full headers of request which caused this issue.

Thanks!

Comment by Pavel Bucek [ 16/Sep/15 ]

feel free to reopen with more info





[TYRUS-411] NullPointerException caused in GrizzlyServerFilter if Connection header is missing Created: 14/Sep/15  Updated: 15/Sep/15  Resolved: 15/Sep/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.11
Fix Version/s: 1.12

Type: Bug Priority: Major
Reporter: graham.gibbons Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

curl -v -i -N -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" http://localhost:8080/

This seems to be a regression caused by the fix for TYRUS-55

Exception:
GRIZZLY0013: Exception during FilterChain execution [org.glassfish.grizzly.filterchain.DefaultFilterChain] [Http-Kernel(3) SelectorRunner]
java.lang.NullPointerException: null
at org.glassfish.tyrus.core.Handshake.validate(Handshake.java:272) ~[tyrus-core-1.11.jar:na]
at org.glassfish.tyrus.core.Handshake.checkForHeader(Handshake.java:265) ~[tyrus-core-1.11.jar:na]
at org.glassfish.tyrus.core.Handshake.createServerHandshake(Handshake.java:231) ~[tyrus-core-1.11.jar:na]
at org.glassfish.tyrus.core.ProtocolHandler.handshake(ProtocolHandler.java:208) ~[tyrus-core-1.11.jar:na]
at org.glassfish.tyrus.core.TyrusWebSocketEngine.upgrade(TyrusWebSocketEngine.java:399) ~[tyrus-core-1.11.jar:na]
at org.glassfish.tyrus.container.grizzly.server.GrizzlyServerFilter.handleHandshake(GrizzlyServerFilter.java:256) ~[tyrus-container-grizzly-server-1.11.jar:na]
at org.glassfish.tyrus.container.grizzly.server.GrizzlyServerFilter.handleRead(GrizzlyServerFilter.java:202) ~[tyrus-container-grizzly-server-1.11.jar:na]
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119) ~[grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.strategies.SameThreadIOStrategy.executeIoEvent(SameThreadIOStrategy.java:103) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545) [grizzly-framework-2.3.15-gfa.jar:2.3.15-gfa]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_11]



 Comments   
Comment by Pavel Bucek [ 15/Sep/15 ]

fixed in the master branch.

Thanks for reporting this.





[TYRUS-317] Allow server configuration using WebSocketContainer or WebSocketAddOn Created: 11/Apr/14  Updated: 14/Sep/15  Resolved: 13/May/14

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: 1.5
Fix Version/s: 1.6

Type: Improvement Priority: Major
Reporter: delhard Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

J2SE 6



 Description   

I am adding WebSocket support to a J2SE-based server application using the embedded grizzly server. It needs to be able to listen on multiple ports and support wss as well as ws connections.

The GrizzlyServerContainer is not usable, because it creates the HttpServer instance listening on a single port, and cannot be configured for SSL or additional ports because the server is private and inaccessible.

I can create and configure my own HttpServer instance with all of the server config I want, but I can't make it support WebSockets because the WebSocketAddOn is package private.

I have worked around this by creating my own ServerContainer and a public subclass of WebSocketAddOn in a class in org.glassfish.tyrus.container.grizzly.server in my own code, but this is a hack that shouldn't be required.

Can we either:

  • add a method to access the server inside the GrizzlyServerContainer
  • make WebSocketAddOn public so it can be used to add WebSocket support to a self-configured server.


 Comments   
Comment by Pavel Bucek [ 16/Apr/14 ]

Hi,

I think we can make WebSocketAddOn public to unblock you.

But this is a nice opportunity for contribution. I don't know all possible requirements you might have, so if you can then post your version of org.glassfish.tyrus.container.grizzly.server.GrizzlyServerContainer, it might help others to achieve same task. After that, you could create a pull request which would enable to set this advanced configuration by direct access to GrizzlyServerContainer or maybe better by using server properties.

Anyway, thanks for the feedback! "Fix" should be in the master branch in one day or so.

Regards,
Pavel

Comment by delhard [ 16/Apr/14 ]

Thanks for the quick response.

To be clear, the only change I made to the tyrus packages was to add a public subclass of WebSocketAddOn.

I have a ServerContainer that does what I need, but it is rather specific to our application, and not really a generic replacement for GrizzlyServerContainer.

I wouldn't be averse to making the changes and submitting a pull request, but it does raise some issues of backward compatibility. The ServerContainer and GrizzlyServerContainer methods are kind of assuming that there will only be one port, so the start method includes the port and root.

We could add another start method that takes additional parameters to be able to specify interface and SSL config to deal with expanding the configuration of the listening port, and add a separate methods to add and remove additional ports, but I dislike the asymmetry between the first and subsequent ports.

Another option might be to add a start method that would take a collection of listener definitions (port, optional host, and optional SSL config), and have the existing start method just define the single listener and call that, and also add methods to dynamically add and remove listeners.

Opinions?

Comment by Pavel Bucek [ 17/Apr/14 ]

latter sounds good, especially keeping the backward compatibility..

It might be nice to fix current naming issues, create GrizzlyServerContainer which would implement ServerContainer and rename existing GrizzlyServerContainer to GrizzlyServerContainerFactory or something like that, to make clear distinction between these two implementations.

Then "standard" Server class from tyrus-server module can be used for simple usecases and GrizzlyServerContainerFactory (with method which can accept collection of grizzly specific Listeners) for more advanced usecases.

does that make sense?

BTW, WebSocketAddOn is now public, so you can remove at least some portion of your workaround..

Comment by delhard [ 28/Apr/14 ]

I am looking at this and have code changes largely ready, but I am having an issue that the repository doesn't seem to build. Not because of my changes but in general. A clean clone of the tyrus repo on github fails a mvn compile with dependency issues in the Samples Bundle.

I'm not sure if this is my environment or just the current state of the repository...

Comment by Pavel Bucek [ 28/Apr/14 ]

can you please share reported issue? I don't see any build issues ATM, but I might have spoiled local maven repository..

Comment by delhard [ 28/Apr/14 ]
[INFO] ------------------------------------------------------------------------
[INFO] Building Tyrus Samples Bundle 1.6-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] tyrus ............................................. SUCCESS [  0.002 s]
[INFO] tyrus-archetypes .................................. SUCCESS [  0.000 s]
[INFO] Tyrus Echo Archetype .............................. SUCCESS [  0.409 s]
[INFO] Tyrus BOM ......................................... SUCCESS [  0.000 s]
[INFO] Tyrus Samples ..................................... SUCCESS [  0.001 s]
[INFO] Tyrus Auction Sample .............................. SUCCESS [  0.639 s]
[INFO] Tyrus Container SPI ............................... SUCCESS [  0.970 s]
[INFO] Tyrus Core ........................................ SUCCESS [  3.228 s]
[INFO] Tyrus Client ...................................... SUCCESS [  0.153 s]
[INFO] Tyrus Container Modules ........................... SUCCESS [  0.000 s]
[INFO] Tyrus Grizzly Client Container .................... SUCCESS [  0.244 s]
[INFO] Tyrus Server ...................................... SUCCESS [  0.128 s]
[INFO] Tyrus Grizzly Server Container .................... SUCCESS [  0.496 s]
[INFO] Tyrus Servlet Bundle .............................. SUCCESS [  0.111 s]
[INFO] Tyrus Tests ....................................... SUCCESS [  0.001 s]
[INFO] Tyrus Test Tools .................................. SUCCESS [  0.063 s]
[INFO] Tyrus CDI Sample .................................. SUCCESS [  0.133 s]
[INFO] Tyrus Chat Sample ................................. SUCCESS [  0.063 s]
[INFO] Tyrus Draw Sample ................................. SUCCESS [  0.025 s]
[INFO] Tyrus JDK Client Container ........................ SUCCESS [  0.215 s]
[INFO] Tyrus Echo Sample ................................. SUCCESS [  0.030 s]
[INFO] Tyrus Dart Echo Sample ............................ SUCCESS [  0.026 s]
[INFO] Tyrus Secure Echo Sample .......................... SUCCESS [  0.028 s]
[INFO] Tyrus Programmatic Echo Sample .................... SUCCESS [  0.033 s]
[INFO] Tyrus Simple Life Sample .......................... SUCCESS [  0.024 s]
[INFO] Tyrus Bundles ..................................... SUCCESS [  0.001 s]
[INFO] Tyrus Samples Bundle .............................. FAILURE [  0.054 s]
[INFO] Tyrus Standalone Client ........................... SKIPPED
[INFO] Tyrus Containers For Glassfish .................... SKIPPED
[INFO] Tyrus CDI Component Provider ...................... SKIPPED
[INFO] Tyrus EJB Component Provider ...................... SKIPPED
[INFO] Tyrus Websocket RI Archive ........................ SKIPPED
[INFO] Tyrus Websocket RI Bundle ......................... SKIPPED
[INFO] Tyrus InMemory Container .......................... SKIPPED
[INFO] Tyrus Documentation ............................... SKIPPED
[INFO] Tyrus Extension Modules ........................... SKIPPED
[INFO] Tyrus CLI Client .................................. SKIPPED
[INFO] Tyrus Monitoring JMX .............................. SKIPPED
[INFO] Tyrus Extension - Per Message Deflate ............. SKIPPED
[INFO] Tyrus End-to-End Tests ............................ SKIPPED
[INFO] Tyrus End-to-End Application Config Tests ......... SKIPPED
[INFO] Tyrus End-to-End Non-deployable Tests ............. SKIPPED
[INFO] Tyrus End-to-End Standard Config Tests ............ SKIPPED
[INFO] Tyrus Server Integration Tests .................... SKIPPED
[INFO] Tyrus Servlet Async Tests ......................... SKIPPED
[INFO] Tyrus Autobahn Echo Server ........................ SKIPPED
[INFO] Tyrus Servlet Basic Tests ......................... SKIPPED
[INFO] Tyrus Servlet Dynamic Deploy Test ................. SKIPPED
[INFO] Tyrus Servlet No App Config ....................... SKIPPED
[INFO] Tyrus Servlet One App Config ...................... SKIPPED
[INFO] Tyrus Servlet RemoteEndpoint Timeout .............. SKIPPED
[INFO] Tyrus Servlet Session Closing ..................... SKIPPED
[INFO] Tyrus Servlet Two App Config ...................... SKIPPED
[INFO] Tyrus Servlet Monitoring Test ..................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.130 s
[INFO] Finished at: 2014-04-28T15:54:40-07:00
[INFO] Final Memory: 43M/445M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project tyrus-samples: Could not resolve dependencies for
project org.glassfish.tyrus.bundles:tyrus-samples:pom:1.6-SNAPSHOT: The following artifacts
could not be resolved: org.glassfish.tyrus.samples:tyrus-sample-auction:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-cdi:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-chat:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-draw:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-echo:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-echo-dart:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-echo-https:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-programmatic-echo:zip:project-src:1.6-SNAPSHOT,
org.glassfish.tyrus.samples:tyrus-sample-simplelife:zip:project-src:1.6-SNAPSHOT:
Could not find artifact org.glassfish.tyrus.samples:tyrus-sample-auction:zip:project-src:1.6-SNAPSHOT -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :tyrus-samples

It seems to have successfully built all of the things it is complaining about being unable to find. And it seems to be complaining about source archives.

It also has a warning at the start of the compile but I don't know if it is relevant:

[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.glassfish.tyrus:tyrus-bom:pom:1.6-SNAPSHOT
[WARNING] 'parent.relativePath' points at org.glassfish.tyrus:tyrus-project instead of net.java:jvnet-parent, please verify your project structure @ line 47, column 13
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
Comment by Pavel Bucek [ 28/Apr/14 ]

what do you execute? mvn clean install? I can see that src packages are generated on my machine. What version of maven do you use?

mine:
$ mvn -v
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00)
Maven home: /Users/pavel/opt/apache-maven-3.2.1
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"

Comment by delhard [ 28/Apr/14 ]

OK, "mvn install" works but "mvn compile" doesn't.

I guess the compile of some of the parts is dependent on pieces not generated by the compile of other parts.

Possibly an issue with the build, but a function of my usage of it.

This should get me unblocked. Thank you.

Comment by Pavel Bucek [ 29/Apr/14 ]

good.

then this is definitely not a build issue. compile does not publish artifacts to your maven repository, so other modules which depend on ones compiled sooner cannot really reliably get that dependency. This is on of the reasons why local repository exists.

note: mvn clean package wouldn't work either. You always must "install" artifact.

Comment by Pavel Bucek [ 29/Apr/14 ]

please note that we cannot accept any contributions unless you sign OCA: http://www.oracle.com/technetwork/community/oca-486395.html

(if you decide to do that, please put me as cc to email with signed agreement - it takes some time to update list present on linked page).

Comment by Pavel Bucek [ 13/May/14 ]

the original problem was fixed; the subsequent contribution is not tied to this issue.

Comment by graham.gibbons [ 14/Sep/15 ]

This was never fixed properly since the WebSocketAddOn constructor is package private. The constructor needs to be public





[TYRUS-409] IllegalStateException is thrown when close(CloseReason closeReason) method is called and session is already closed Created: 10/Sep/15  Updated: 10/Sep/15  Resolved: 10/Sep/15

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: None
Fix Version/s: 1.12

Type: Bug Priority: Minor
Reporter: farzad.panahi Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From Session Java EE 7 API:

Once the session is closed, it is no longer valid for use by applications. Calling any of its methods (with the exception of the close() methods) once the session has been closed will result in an IllegalStateException being thrown.

From what I understand, close methods should not throw IllegalStateException when session is closed. But Tyrus will throw IllegalStateException when you call close(CloseReason closeReason) method and the session is closed.

This is due to checkConnectionState(State.CLOSED); at this line.

Also when you look at close method definition:

Throws:
IOException - if there was a connection error closing the connection

It does not say anything about IllegalStateException.

Am I missing something or checkConnectionState(State.CLOSED); should be removed from close method?



 Comments   
Comment by Pavel Bucek [ 10/Sep/15 ]

See Session javadoc (class level):

Once the session is closed, it is no longer valid for use by applications. Calling any of its methods (with the exception of the close() methods) once the session has been closed will result in an IllegalStateException being thrown. Developers should retrieve any information from the session during the Endpoint.onClose(javax.websocket.Session, javax.websocket.CloseReason) method. Following the convention of Closeable calling the Session close() methods after the Session has been closed has no effect.

resolving as "work as designed".

Comment by farzad.panahi [ 10/Sep/15 ]

But isn't the Java doc basically saying that calling close methods when session is closed will not throw IllegalStateException?

Comment by Pavel Bucek [ 10/Sep/15 ]

well.. no. Or it shouldn't.

The problem might be word "methods", which is confusing - it should be "method". Anyway, it explicitly mentions version without any parameter, so it is still "ok". That sentence is trying to say something like: "we cannot (and don't wan't) override close() method from Closable iface, so it cannot throw ISE; this method must stay idempotent. The ISE applies to other methods."

The idea behind this is that if you call close(CloseReason) on already closed Session and you won't get ISE, you might think (and actually you don't have any other means how to verify that) that the close reason you put as parameter was sent on the wire; which is not the case for closed session, since there might not even be TCP connection underneath + runtime would be violating WebSocket protocol if it allows to send close frame twice.

Comment by farzad.panahi [ 10/Sep/15 ]

Thanks Pavel. What you say totally makes sense. I think the wording of javadoc can be improved : )





[TYRUS-403] tyrus client broken on android with SSL Created: 26/Jul/15  Updated: 27/Jul/15  Resolved: 26/Jul/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.11
Fix Version/s: None

Type: Bug Priority: Major
Reporter: ymenager Assignee: Pavel Bucek
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Android 5.0


Issue Links:
Duplicate
duplicates TYRUS-402 Unable to use Tyrus in android applli... Resolved
Tags: android, ssl

 Description   

tyrus seems hopelessly broken on android using 5.0.

The wrap bug (TYRUS-402) is the first blow. I've managed to work around it by adding code to sanitize the buffer array parameter, which seemed to fix the problem:

@Override
public SSLEngineResult wrap(ByteBuffer[] srcs, int offset, int length, ByteBuffer dst) throws SSLException {
ArrayList<ByteBuffer> list = new ArrayList<ByteBuffer>();
for (ByteBuffer bb : srcs) {
if( bb != null )

{ list.add(bb); }

}
return wrapped.wrap(list.toArray(new ByteBuffer[list.size()]), offset, length, dst);
}

but unfortunately things still occasionally and randomly break during handshake.

I've seen two errors happening, one is:

07-25 23:24:02.295 3641-3659/? W/nectionFactoryTyrusImpl﹕ Server connection failed: SSL handshake has failed
javax.websocket.DeploymentException: SSL handshake has failed
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:396)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.access$000(GrizzlyClientSocket.java:103)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:235)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:231)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.connect(GrizzlyClientSocket.java:249)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer.openClientSocket(GrizzlyClientContainer.java:95)
at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:663)
at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:712)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:866)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:81)
at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:511)
at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:373)
at com.kloudtek.idvtek.client.net.websocket.GWConnectionFactoryTyrusImpl$1.run(GWConnectionFactoryTyrusImpl.java:65)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at org.glassfish.grizzly.ssl.SSLUtils.getSSLPacketSize(SSLUtils.java:231)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:593)
at org.glassfish.grizzly.ssl.SSLFilter.doHandshakeStep(SSLFilter.java:312)
at org.glassfish.grizzly.ssl.SSLBaseFilter.doHandshakeStep(SSLBaseFilter.java:552)
at org.glassfish.grizzly.ssl.SSLBaseFilter.handleRead(SSLBaseFilter.java:273)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
            at java.lang.Thread.run(Thread.java:818)

The other one I don't have a full stacktrace anymore, but it was hitting this line:

throw new SSLException("Unsupported record version major=" + major + " minor=" + minor);

where major = 1 and minor = 12

Those error aren't happening all the time, but still quite often (maybe 30% of the time or something like that)



 Comments   
Comment by Pavel Bucek [ 26/Jul/15 ]

duplicate of TYRUS-402

Comment by Pavel Bucek [ 26/Jul/15 ]

Hi ymenager,

plase update TYRUS-402 if you have any new findings; add your case - you can replace grizzly with latest snapshot, it should have fix for TYRUS-402 integrated. Can you reproduce issue you see even after that?

Thanks,
Pavel

Comment by ymenager [ 27/Jul/15 ]

Ah ok I was worried i had messed up things by having done the other issue using "clone"

I'll check against snapshot and put a comment on 402 on the results





[TYRUS-386] Dalvik class loader rejects TyrusEnpointWrapper Created: 11/Oct/14  Updated: 23/Jul/15  Resolved: 16/Oct/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.8.3
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: geoff@crunchware.com Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Android Virtual Device running on 64 bit Windows 7 Pro - SDK 17, Android 4.2.2-


Issue Links:
Duplicate
is duplicated by TYRUS-387 Unable to use Tyrus in android applli... Resolved
is duplicated by TYRUS-402 Unable to use Tyrus in android applli... Resolved

 Description   

Attempting to establish a connection to an existing Websocket server instance fails when using version 1.8.3 of TYRUS. Running with v1.8 succeeds.

The log output using 1.8.3 includes...

10-10 18:55:36.914: I/Connecting to server(9967): 10.10.3.102:8080
10-10 18:55:37.004: W/dalvikvm(9967): VFY: unable to resolve exception class 1243 (Ljava/lang/ReflectiveOperationException
10-10 18:55:37.004: W/dalvikvm(9967): VFY: unable to find exception handler at addr 0x1ee
10-10 18:55:37.004: W/dalvikvm(9967): VFY: rejected Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;
.<init> (Ljavax/websocket/Endpoint;
Ljava/lang/Class;
Ljavax/websocket/EndpointConfig;
Lorg/glassfish/tyrus/core/ComponentProviderService;
Ljavax/websocket/WebSocketContainer;
Ljava/lang/String;
Ljavax/websocket/server/ServerEndpointConfig$Configurator;
Lorg/glassfish/tyrus/core/TyrusEndpointWrapper$SessionListener;
Lorg/glassfish/tyrus/core/cluster/ClusterContext;
Lorg/glassfish/tyrus/core/monitoring/EndpointEventListener;
Ljava/lang/Boolean;)V
10-10 18:55:37.004: W/dalvikvm(9967): VFY: rejecting opcode 0x0d at 0x01ee



 Comments   
Comment by Pavel Bucek [ 16/Oct/14 ]

fix merged to the master branch (rev 2fca5dbbb4a4bfd361b440694ad43b4e339557f8).

pls note that 4.4.2 supports ReflectiveOperationException; 4.2.2 does not (not sure why). Anyway, I replaced that with generic Exception and it seems to work as expected. Thanks for the bug report!





[TYRUS-387] Unable to use Tyrus in android appllication Created: 15/Oct/14  Updated: 23/Jul/15  Resolved: 16/Oct/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8.3
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: andreas_jansson Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Android 4.2.2


Issue Links:
Cloners
is cloned by TYRUS-402 Unable to use Tyrus in android applli... Resolved
Duplicate
duplicates TYRUS-386 Dalvik class loader rejects TyrusEnpo... Resolved

 Description   

I am using tyrus client library on android, but runtime error occurs. See details from logcat below. The same scenario works with Tyrus 1.7.

I/SurfaceFlinger( 303): id=58(15) createSurf 0x410803c4 (1x1),2 flag=404, iellotyrus
I/MainActivity( 5391): Hello Tyrus started!
I/MainActivity( 5391): Hello Tyrus thread running!
I/dalvikvm( 5391): Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1616 'Lorg/osgi/framework/SynchronousBundleListener;'
W/dalvikvm( 5391): Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
I/dalvikvm( 5391): Could not find method org.glassfish.tyrus.core.OsgiRegistry.getInstance, referenced from method org.glassfish.tyrus.core.ReflectionHelper.getOsgiRegistryInstance
W/dalvikvm( 5391): VFY: unable to resolve static method 10918: Lorg/glassfish/tyrus/core/OsgiRegistry;.getInstance ()Lorg/glassfish/tyrus/core/OsgiRegistry;
I/dalvikvm( 5391): Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1616 'Lorg/osgi/framework/SynchronousBundleListener;'
W/dalvikvm( 5391): Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
W/dalvikvm( 5391): VFY: unable to find class referenced in signature (Lorg/glassfish/tyrus/core/OsgiRegistry
W/dalvikvm( 5391): VFY: rejected Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;.<init> (Ljavax/websocket/Endpoint;Ljava/lang/Class;Ljavax/websocket/EndpointConfig;Lorg/glassfish/tyrus/core/ComponentProviderService;Ljavax/websocket/WebSocketContainer;Ljava/lang/String;Ljavax/websocket/server/ServerEndpointConfig$Configurator;Lorg/glassfish/tyrus/core/TyrusEndpointWrapper$SessionListener;Lorg/glassfish/tyrus/core/cluster/ClusterContext;Lorg/glassfish/tyrus/core/monitoring/EndpointEventListener;Ljava/lang/Boolean;)V
W/dalvikvm( 5391): VFY: rejected Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;.<init> (Ljavax/websocket/Endpoint;Ljava/lang/Class;Ljavax/websocket/EndpointConfig;Lorg/glassfish/tyrus/core/ComponentProviderService;Ljavax/websocket/WebSocketContainer;Ljava/lang/String;Ljavax/websocket/server/ServerEndpointConfig$Configurator;Lorg/glassfish/tyrus/core/TyrusEndpointWrapper$SessionListener;Lorg/glassfish/tyrus/core/cluster/ClusterContext;Lorg/glassfish/tyrus/core/monitoring/EndpointEventListener;Ljava/lang/Boolean;)V
W/dalvikvm( 5391): Verifier rejected class Lorg/glassfish/tyrus/core/TyrusEndpointWrapper;
I/SurfaceFlinger( 303): id=58 Removed iellotyrus (4/5)
I/SurfaceFlinger( 303): id=58 Removed iellotyrus (-2/5)



 Comments   
Comment by andreas_jansson [ 15/Oct/14 ]

I have a sample app to reproduce, but I'm not sure how to attach it to the bug?

Creating a similar app can be done using the android SDK like this:

1. Create project
android create project --target 1 --name HelloTyrus --path HelloTyrus --activity MainActivity --package com.example.hellotyrus

2. Download https://repo1.maven.org/maven2/org/glassfish/tyrus/bundles/tyrus-standalone-client/1.8.3/tyrus-standalone-client-1.8.3.jar and put in libs

3. Add some Tyrus client code to MainActivity.java

4.Build
ant debug

5. Install on android device (I have not tested emulator, but I assume that gived same result)
adb install bin/HelloTyrus-debug.apk

6. Check logs
adb logcat | grep -i tyrus

7. Start app

Comment by Pavel Bucek [ 16/Oct/14 ]

fixed in the trunk (rev 2fca5dbbb4a4bfd361b440694ad43b4e339557f8).

Thanks for the instructions!

Comment by hsamu [ 01/Jan/15 ]

I am seeing this on a 4.4.2 tablet with tyrus 1.9. Java code uses javax.websocket API:

import javax.websocket.WebSocketContainer;
WebSocketContainer websocket_container = ContainerProvider.getWebSocketContainer();

I tried building with both Java 1.6 and 1.7, and get the same result. It worked in an emulator on linux with Java 1.7...

12-31 15:29:27.144 17162-17162/com.xxx.pushservice I/dalvikvm﹕ Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1719 'Lorg/osgi/framework/SynchronousBundleListener;'
12-31 15:29:27.144 17162-17162/com.xxx.pushservice W/dalvikvm﹕ Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
12-31 15:29:27.144 17162-17162/com.xxx.pushservice I/dalvikvm﹕ Could not find method org.glassfish.tyrus.core.OsgiRegistry.getInstance, referenced from method org.glassfish.tyrus.core.ReflectionHelper.getOsgiRegistryInstance
12-31 15:29:27.144 17162-17162/com.xxx.pushservice W/dalvikvm﹕ VFY: unable to resolve static method 11655: Lorg/glassfish/tyrus/core/OsgiRegistry;.getInstance ()Lorg/glassfish/tyrus/core/OsgiRegistry;
12-31 15:29:27.145 17162-17162/com.xxx.pushservice I/dalvikvm﹕ Failed resolving Lorg/glassfish/tyrus/core/OsgiRegistry; interface 1719 'Lorg/osgi/framework/SynchronousBundleListener;'
12-31 15:29:27.145 17162-17162/com.xxx.pushservice W/dalvikvm﹕ Link of class 'Lorg/glassfish/tyrus/core/OsgiRegistry;' failed
12-31 15:29:27.145 17162-17162/com.leapfrog.pushservice W/dalvikvm﹕ VFY: unable to find class referenced in signature (Lorg/glassfish/tyrus/core/OsgiRegistry
12-31 15:29:27.163 17162-17162/com.xxx.pushservice W/dalvikvm﹕ threadid=1: thread exiting with uncaught exception (group=0x41a28ce0)
12-31 15:29:27.163 17162-17162/com.xxx.pushservice W/dalvikvm﹕ threadid=1: uncaught exception occurred
12-31 15:29:27.163 17162-17162/com.xxx.pushservice W/System.err﹕ java.lang.RuntimeException: Unable to instantiate service com.xxx.services.PusherService: java.lang.NullPointerException





[TYRUS-361] JVM does not exits if shared transport is enabled Created: 07/Aug/14  Updated: 12/Jun/15  Resolved: 08/Aug/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8
Fix Version/s: 1.8.1, 1.9

Type: Bug Priority: Major
Reporter: josem.palomar Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Steps to reproduce:

  • Create a new ClientManager and enable shared transport
  • Create a new Session connecting against a web socket endpoint
  • Close Session

Problem seems to be located at org.glassfish.tyrus.container.grizzly.client.GrizzlyTransportTimeoutFilter due to its executor service never shutdown properly.



 Comments   
Comment by josem.palomar [ 07/Aug/14 ]

I wrote a small program to reproduce problem:

import java.net.URI;

import javax.websocket.Endpoint;
import javax.websocket.EndpointConfig;
import javax.websocket.Session;

import org.glassfish.tyrus.client.ClientManager;
import org.glassfish.tyrus.client.ClientProperties;

public class TyrusClientTest {

public static void main(String[] args) throws Exception {

ClientManager clientManager = ClientManager.createClient();
clientManager.getProperties().put(ClientProperties.SHARED_CONTAINER, true);
clientManager.getProperties().put(ClientProperties.SHARED_CONTAINER_IDLE_TIMEOUT, 5);

Session session = clientManager.connectToServer(new Endpoint() {

@Override
public void onOpen(Session session, EndpointConfig config) {
}

}, new URI("ws://localhost:8080/notification/listen"));

session.close();

}

}

Comment by Pavel Bucek [ 07/Aug/14 ]

Hi Josem,

thanks for the bug report! Your analysis is correct and the bug reproduces is also greatly appreciated, I wish every issue is like this one .

Fix should be merged to the trunk in a day or so.

Regards,
Pavel

Comment by Pavel Bucek [ 08/Aug/14 ]

fix was merged to the master branch (rev 17108682a651485ef98a014df04c670a00c501f5)





[TYRUS-400] Improved exceptions? Created: 02/Jun/15  Updated: 02/Jun/15

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.10
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: richardburton Assignee: Pavel Bucek
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As a developer, I'm certain you can understand the pain a poorly articulated exception causes. It's like when a user opens up a ticket and says "Hey, it doesn't work." The following exception is without meaning and serves no purpose other than spitting up blood.

Caused by: javax.websocket.DeploymentException: Handshake response not received.
at org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:655)
at org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:673)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:826)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:496)
at org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:348)

I'm able to connect to the server using ws://localhost:8080/context/endpoint without an issue but the Tyrus client simply throws a worthless error message without any meaningful information.

e.g., can it not find the host? (In this case it should), Is it connected but not getting any response back? (Not being connected since @OnOpen isnt called), and the list goes on.

I started to look at ClientManager#connectToServer but after trying to read 200 lines of code with nested anonymous classes, inline versions of classes with different implementations, etc. I thought I was watching the assembling of Franklinstein with all the things being hacked together in a single method.



 Comments   
Comment by richardburton [ 02/Jun/15 ]

Okay, I tried to use the standalone client JDK as shown here https://tyrus.java.net/dependencies.html

And this is the exception I receive.

java.lang.RuntimeException: javax.websocket.DeploymentException: org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer

at org.glassfish.tyrus.client.ClientManager.<init>(ClientManager.java:269)
at org.glassfish.tyrus.client.ClientManager.createClient(ClientManager.java:237)
at org.glassfish.tyrus.client.ClientManager.createClient(ClientManager.java:216)

Seriously? What does this even mean?

Please update ClientManager line 269 and change this:

throw new RuntimeException(collector.composeComprehensiveException());

to something actually comprehensive like "Unable to find 'org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer'" Please make sure you include tyrus-container-grizzly-server". Why would someone include the container grizzle server when you're using just the client?

Comment by Pavel Bucek [ 02/Jun/15 ]

The first exception means what is says - Tyrus was able to send handshake request, but it did not received any response within defined timeout.

The second one is little bit cryptic and you are correct that composeComprehensiveException should take the exception type into account as well (in this case, it seems like CNFE was reduced to getMessage(), which returns just the name of the class). Feel free to submit a pull request if you want (make sure you have OCA signed) or I'll take care of it before next release.

I'm not sure what your last question is referring to - we currently provide two client transports, I don't know why are you mentioning grizzly-server module.

Thanks.

Comment by richardburton [ 02/Jun/15 ]

To resolve the second exception, I had to add that jar which contained the missing class.

In the first case, it would be very useful to state how far the library got before timing out. e.g., it was able to connect to the server but didn't receive a response.

Comment by Pavel Bucek [ 02/Jun/15 ]

ad 1) you can enable logging, that should provide that kind of information; see https://tyrus.java.net/documentation/1.10/user-guide.html#d0e1475





[TYRUS-398] Access to underlying container buffers Created: 08/May/15  Updated: 08/May/15

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.10
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jdv Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: container, grizzly, transport

 Description   

We have a client Endpoint that happens to occasionally need to push a fair amount of data back to the peer via write(), and during performance testing we noted that the data was being chunked up into 16K buffers.

While searching for a way to tweak the buffer sizes similar to .NET/C# ClientWebSocketOptions.SetBuffer it looks like we do not have access from the Endpoint to the underlying container transport buffers. Ideally, something like exposing TCPNIOTransportBuilder.writeBuffersSize() params (perhaps via GrizzlyClientProperties?) for Grizzly to give us a way to hint at larger buffers.

If Grizzly is slowly being deprecated in favour of the NIO transport container, a way to change the send/recv buffers beyond the fixed 4K/17K sizes in 1.10 is requested.



 Comments   
Comment by jdv [ 08/May/15 ]

I suppose this should be tagged "client".





[TYRUS-397] Client try to connect directly to the server when a proxy (which is down) is configured Created: 24/Apr/15  Updated: 24/Apr/15  Resolved: 24/Apr/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.9
Fix Version/s: 1.11

Type: Bug Priority: Major
Reporter: david.regnier Assignee: Pavel Bucek
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Duplicate
duplicates TYRUS-394 Proxy bypassed on Linux but not on Wi... Resolved
Tags: proxy

 Description   

Context: use the JdkClientContainer

How to reproduce:

client <> proxy down <> server
(with client which can reach server directly).

Result: the client communicates directly with the server.

If we have configured the client with a proxy, we do not want the client to communicate with the server even if the proxy is down/unreachable.

Related code: JdkClientContainer#processProxy():

addProxies(proxySelector, uri, "socket", proxies);
addProxies(proxySelector, uri, "https", proxies);
addProxies(proxySelector, uri, "http", proxies);
proxies.add(Proxy.NO_PROXY);

(line 387)

Proxy.NO_PROXY is always added whatever the proxy configuration is.

Possible fix:

if(proxies.isEmpty())

{ proxies.add(Proxy.NO_PROXY); }

 Comments   
Comment by Pavel Bucek [ 24/Apr/15 ]

isn't this already fixed by https://github.com/tyrus-project/tyrus/commit/963c5159e4f884b43918cb2a323a4865074788c0 ? (which is in 1.10)

Comment by david.regnier [ 24/Apr/15 ]

OK cool thank you -> i will use 1.10 (invalid issue -> sorry)

Comment by Pavel Bucek [ 24/Apr/15 ]

no problem





[TYRUS-394] Proxy bypassed on Linux but not on Windows Created: 23/Jan/15  Updated: 24/Apr/15  Resolved: 29/Jan/15

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: anbb Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by TYRUS-397 Client try to connect directly to the... Resolved
Tags: proxy

 Description   

Same implementation of a websocket client that uses an invalid proxy behaves differently on different operating systems.

On Linux operating systems it connects directly after 30 seconds but on Windows operating system it throws a "java.net.ConnectException: Connection timed out: no further information ".

Stack trace from Windows platform :

java.net.ConnectException: Connection timed out: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:206)
at org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.connected(TCPNIOConnectorHandler.java:154)
at org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:258)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:552)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.executeIoEvent(WorkerThreadIOStrategy.java:103)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.executeIoEvent(AbstractIOStrategy.java:89)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeyEvents(SelectorRunner.java:414)
at org.glassfish.grizzly.nio.SelectorRunner.iterateKeys(SelectorRunner.java:383)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:347)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:278)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Unknown Source)



 Comments   
Comment by Pavel Bucek [ 27/Jan/15 ]

the change fixing this issue has been committed and snapshot published to maven.java.net repo - can you please verify the current behaviour?

Thanks!

Comment by Pavel Bucek [ 29/Jan/15 ]

fixed in master branch (963c5159e4f884b43918cb2a323a4865074788c0)





[TYRUS-396] Passing info from ServerEndpointCondig#Configurator to Endpoint instance Created: 16/Mar/15  Updated: 18/Mar/15

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: 1.10
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to WEBSOCKET_SPEC-235 Passing values from ServerEndpointCon... Open

 Description   

Spec issue - WEBSOCKET_SPEC-235

I believe we should try to make that work at in Tyrus; some ideas:

  • TyrusSession could expose HandshakeRequest
  • HandshakeRequest could expose `Map<String, Object>` (userProperties) which will be added to Session#getUserProperties..


 Comments   
Comment by Pavel Bucek [ 18/Mar/15 ]

there is no good solution for that issue, if we limit the change only to WebSocket API implementation; all we can do here is to introduce another ServerEndpointConfig#Configurator descendant (let's call it TyrusServerConfigurator), which would somehow provide access to any object (most likely userProperties).

Since we are extending original Configurator, we cannot change the method signatures. Also the Configurator is currently singleton, so we cannot easily set the value and let the code get it - the concurrent invocation won't be handled correctly. I see two possible approaches:

  • keep singleton, set the userProperties as ThreadLocal
  • don't keep the singleton, make new instance for each endpoint instance

Currently I don't particularly like either of those, so if anyone has better suggestion, I'm all ears.. Thanks!





[TYRUS-395] Getting started example typo Created: 04/Mar/15  Updated: 16/Mar/15  Resolved: 16/Mar/15

Status: Resolved
Project: tyrus
Component/s: samples
Affects Version/s: 1.10
Fix Version/s: 1.11

Type: Bug Priority: Trivial
Reporter: lathspell42 Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour


 Description   

https://tyrus.java.net/documentation/1.10/index/getting-started.html
In "1.1.4. Tyrus in Standalone Mode", the example says

Server server = new Server("localhost", 8025, "/websocket", null, EchoEndpoint.class);

It should be "/websockets" (plural) to work with the client in "1.1.2. Client Endpoint"



 Comments   
Comment by Pavel Bucek [ 16/Mar/15 ]

thanks!

fixed merged to the master branch (0b8001688cb9eab406a22ed75b48b0effec669b9)





[TYRUS-390] Tyrus server endpoint @OnMessage method not triggered Created: 08/Dec/14  Updated: 23/Feb/15  Resolved: 23/Feb/15

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: 1.8.3
Fix Version/s: 1.11

Type: Bug Priority: Major
Reporter: stephenhartley Assignee: Pavel Bucek
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

java version "1.7.0_72" Java(TM) SE Runtime Environment (build 1.7.0_72-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
Windows 7

Client and server run on same machine so no proxy/network interference.



 Description   

Question originally raised on stackoverflow:
http://stackoverflow.com/questions/27016805/

I am attempting to run a simple websocket example using Tyrus 1.8.3 and the javax.websocket API, following https://blog.openshift.com/how-to-build-java-websocket-applications-using-the-jsr-356-api/ as a guide.

Using annotations, I have created a simple server endpoint and a client endpoint which triggers a method annotated with@OnOpen correctly. However, when I send a message from the client, the method with @OnMessage is not triggered on the server side.

I have also written a simple Javascript client to connect to the same server endpoint and this also does not trigger the @OnMessage method, so I am suspecting there is an issue on the server side.

I have raised the log level to FINE as nothing is reported at INFO level. From the logs it looks like the websocket upgrade is successful and the connection is opened OK. A javax.naming.NoInitialContextException is thrown on both client and server but I'm not sure if this is relevant...

I have uploaded all of the code to github here: https://github.com/stephenhartley/websocket-demo
The logs files can be viewed in the logs folder.

I cloned github.com/shekhargulati/wordgame which is the original author's codebase and the @OnMessage method is not triggered in that demo code either...

Client and server run on same machine so no proxy/network interference.



 Comments   
Comment by Pavel Bucek [ 09/Dec/14 ]

the main issue here is that the demo works fine on my box (Mac Os X, 10.10.1, Java 7_u72).

Just a thought - do you have any firewall enabled? It can often act as a http proxy..

Comment by Pavel Bucek [ 23/Feb/15 ]

closing as incomplete, feel free to reopen with new info.





[TYRUS-391] Tyrus reconnect handler not reached on Android Created: 01/Jan/15  Updated: 22/Jan/15  Resolved: 22/Jan/15

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.9
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: MisterNibble Assignee: Pavel Bucek
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Android 4.4.2 - Note II N7100 (WiFi/cellular)
Android 5.0 - Nexus 4 (WiFi/cellular) and Genymotion (Ethernet)


Tags: android

 Description   

I managed to get client reconnects working using the built-in Java 7 NIO2 client on the desktop (Windows 8.1 x64, JDK 8) with Tyrus 1.9 and prior versions as is described here: https://tyrus.java.net/documentation/1.9/user-guide.html#d0e1311.

Nothing happens on Android (its as if there are no handlers).

See this Stack Overflow question: http://stackoverflow.com/questions/27646513/tyrus-reconnect-handler-not-reached-on-android



 Comments   
Comment by MisterNibble [ 05/Jan/15 ]

I am available to assist reproducing the issue or in testing a possible fix.

Comment by Pavel Bucek [ 06/Jan/15 ]

I'll need more info about your usecase - what is the server and why do you think that connection is closed?

I cannot reproduce when accessing server (grizzly on localhost) from emulator..

Comment by MisterNibble [ 06/Jan/15 ]

The server is GlassFish 4.1 on Ubuntu 12.04 x64, Oracle Java 8, using Tyrus 1.9 and updates to a few essential libraries (GlassFish 4.1 out of the box is completely broken).
The connection is closed because the network is disabled (VM via Windows), Ethernet cable is unplugged, or radio disconnected (no WiFi or 3G etc).
I'll do some debugging to see what happens precisely tomorrow.

Comment by MisterNibble [ 07/Jan/15 ]

For the following code (run when there is no network as the result of a network disconnect) I get no exception, and the error handler is never called.

test.java
RemoteEndpoint.Async remote = session.getAsyncRemote();
String msg = "ping";
if (session.isOpen())
{
  try {
    remote.sendObject(msg);
  }
  catch (IllegalArgumentException ex) {
    methodException(ex);
  }
}

The reconnect handler is never reached (that is the problem), despite an attempt to send something via the socket.

Comment by Pavel Bucek [ 08/Jan/15 ]

Are you sure that `session.isOpen()` returns true in your case?

I created my test project and I see that reconnect handler is always called, no matter how is the connection broken - I tried closing it from server and turning off wifi (using genymotion emulator); feel free to test it and let me know if it reproduces the issue on your side. see https://github.com/pavelbucek/tyrus-391

You will need to modify MainActivity.java (server endpoint URL) and maybe android-sdk path in local.properties. I used android studio, but it should be runnable without it..

Comment by MisterNibble [ 08/Jan/15 ]

Hi Pavel. I am testing your project. I'll get back to you soon with the results. I'll check session.isOpen() too.

Comment by MisterNibble [ 08/Jan/15 ]

_______________________________________
Tested on Genymotion "Nexus 4" with Android 5.0.

[Click button]
01-08 15:22:52.759﹕ ### 0 Button.onClick
01-08 15:22:52.765﹕ ### 1 AsyncTask.doInBackground
01-08 15:22:52.995﹕ ### 2 Tyrus Client onOpen
01-08 15:22:53.085﹕ ### 3 Tyrus Client onMessage: Do or do not, there is no try.

[Disable Network Adapter] -> Nothing happens after 4 minutes
[Click button again]
01-08 15:26:09.176﹕ ### 0 Button.onClick
01-08 15:26:09.178﹕ ### 1 AsyncTask.doInBackground
(30 sec later)
01-08 15:26:39.184﹕ ### 5b Tyrus Client onConnectFailure: javax.websocket.DeploymentException: Connection failed.
...
01-08 15:28:24.212﹕ ### 5b Tyrus Client onConnectFailure: javax.websocket.DeploymentException: Connection failed.
...

[Enable Ethernet & restart application.]
[Click button]
01-08 15:29:49.482﹕ ### 0 Button.onClick
01-08 15:29:49.486﹕ ### 1 AsyncTask.doInBackground
01-08 15:29:49.737﹕ ### 2 Tyrus Client onOpen
01-08 15:29:49.830﹕ ### 3 Tyrus Client onMessage: Do or do not, there is no try.
[Disconnect Ethernet cable] -> Nothing happens after 10 minutes

For whatever reason, the library is not aware of the fact networking is no longer working while a socket is open.

___________________________________
Tested on N7100 "Note 2" with Android 4.4.2

[Click button]
01-08 17:52:23.168﹕ ### 0 Button.onClick
01-08 17:52:23.193﹕ ### 1 AsyncTask.doInBackground
01-08 17:52:23.998﹕ ### 2 Tyrus Client onOpen
01-08 17:52:24.098﹕ ### 3 Tyrus Client onMessage: Do or do not, there is no try.
[Disabled WiFi]
01-08 17:52:38.448﹕ ### 4 Tyrus Client onClose: CloseReason[1006,Closed abnormally.]
01-08 17:52:38.448﹕ ### 5a Tyrus Client onDisconnect: CloseReason[1006,Closed abnormally.]
01-08 17:52:44.063﹕ ### 2 Tyrus Client onOpen
01-08 17:52:44.188﹕ ### 3 Tyrus Client onMessage: Do or do not, there is no try.

Works as expected on the native device. I will investigate further.

Comment by MisterNibble [ 08/Jan/15 ]

_____________________________
Tested on Nexus 4 with Android 5.0.1

01-08 18:03:25.021﹕ ### 0 Button.onClick
01-08 18:03:25.034﹕ ### 1 AsyncTask.doInBackground
01-08 18:03:25.704﹕ ### 2 Tyrus Client onOpen
01-08 18:03:25.865﹕ ### 3 Tyrus Client onMessage: Do or do not, there is no try.
[Disabled WiFi]
01-08 18:03:54.389﹕ ### 4 Tyrus Client onClose: CloseReason[1006,Closed abnormally.]
01-08 18:03:54.389﹕ ### 5a Tyrus Client onDisconnect: CloseReason[1006,Closed abnormally.]
01-08 18:03:59.450﹕ ### 5b Tyrus Client onConnectFailure: javax.websocket.DeploymentException: Connection failed.
...
01-08 18:04:34.931﹕ ### 5b Tyrus Client onConnectFailure: javax.websocket.DeploymentException: Connection failed.
[Re-enabled WiFi]
01-08 18:04:40.219﹕ ### 2 Tyrus Client onOpen
01-08 18:04:40.417﹕ ### 3 Tyrus Client onMessage: Do or do not, there is no try.

Works as expected.

Comment by MisterNibble [ 08/Jan/15 ]

I noticed you are using passing a ClientEndpointConfig instance in connect(). I'd like to use it too, but my code is currently built to use asyncConnectToServer(Object obj, URI path) instead of say asyncConnectToServer(Endpoint endpointInstance, ClientEndpointConfig cec, URI path) - Endpoint is a pure abstract class instead of an interface for some reason. Could not using a ClientEndpointConfig cause a problem?

Comment by Pavel Bucek [ 08/Jan/15 ]

No, that should not be an issue. If it is, you should see that in a log somewhere - actually, I think if you'll have incorrectly defined client endpoint, you should get a DeploymentException returned from asyncConnectToServer(…).get() call.

Anyway, there could be a bug in validation / method scanning, so.. can you share your code? The part with asyncConnectToServer and the endpoint (just method signatures, the implementation should not be relevant) are the most important parts here.

Last but not least - thanks for the tests/verification!

Comment by MisterNibble [ 08/Jan/15 ]

So it looks like my Genymotion installation or VM is ignorant of network issues for whatever reason. What GenyMotion version do you have and what Android image are you using? I'd prefer not to have to give up on Genymotion, that's for sure.

Sure, glad to help. Here are the signatures:

Client.java
@ClientEndpoint(
	encoders =	{ TextEncoder.class },
	decoders =	{	TextDecoder.class }
)
public class Client extends Reporter implements ISocketEndpoint
{
	@OnOpen
	public void onOpen(Session session, EndpointConfig config)

	@OnError
	public void onError(Session session, Throwable ex)

	@OnMessage
	public void onMessage(final Session session, Msg msg) throws IOException, EncodeException

	@OnClose
	public void onClose(Session session, CloseReason reason)
}
Comment by Pavel Bucek [ 09/Jan/15 ]

I used genymotion 2.3.1 (revision 20141107-fd86ec1) and image "Custom Phone - 4.4.4 - API 19 - 762x1280".

From what I see in this discussion, it seems like this is more related to the runtime environment, especially genymotion emulation software. Nevertheless, I still cannot reproduce it on my local box (Mac Os X, 10.10.1); I'm not sure which operating system do you use, but if its MS Windows, I could imagine that it can be an issue (especially when dealing with networking differences/issues).

Comment by MisterNibble [ 10/Jan/15 ]

I think this is indeed a Windows->Genymotion issue; although I would expect better from Windows 8.1 x64 "Professional" - I guess the "pro" part refers to the pretty colors in the Kindergarten Start menu. Oh well...

In the meantime I will focus on testing reconnection on the actual devices, and I'll let you know how it goes.

Comment by MisterNibble [ 21/Jan/15 ]

After removing an error that broke it all - yes it was user error, I can confirm that reconnecting works flawlessly as intended on a Nexus 7 with Android 5.0.1 and N7100 with Android 4.4.2. Its definitely broken in Genymotion (via VirtualBox x64) on Windows 8.1 though.

Comment by Pavel Bucek [ 22/Jan/15 ]

thanks for getting back to this and for your evaluation

closing as "cannot reproduce"; feel free to reopen in case some new facts are discovered.





[TYRUS-393] Incorrect handling of sending whole message during (unfinished) partial message. Created: 14/Jan/15  Updated: 20/Jan/15  Resolved: 20/Jan/15

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Based on discussion and evaluation done in web socket spec mailing list:

https://java.net/projects/websocket-spec/lists/jsr356-experts/archive/2015-01/message/0

following code should do something differently .

session.getBasicRemote().sendText(message, false);
session.getBasicRemote().sendText(message);

current outcome (on the receiver side) is that one whole (or two partial, second is final). will be received; that is not correct, since the sender did not signal that the partial message is closed.

From the spec perspective, it is OK to throw IllegalStateException or even block the execution until the partial message is finished or .. anything else (it is not clearly defined). But we should not do what Tyrus does at the moment.



 Comments   
Comment by Pavel Bucek [ 20/Jan/15 ]

Specification allows implementation to thrown an IllegalStateException, but it is not requires - meaning that implementation can even block the thread and wait until the message is fully sent. Current change combines these two approaches - we will wait (up to defined timeout - currently 3 s) and if the message is not finished, the send* call will fail with IllegalStateException.





[TYRUS-329] Deflate extension fixes - autobahn test suite Created: 13/Jun/14  Updated: 08/Dec/14  Resolved: 08/Dec/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: None
Fix Version/s: 1.10

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

use autobahn test suite 0.6.1+ for verification



 Comments   
Comment by Pavel Bucek [ 08/Dec/14 ]

We don't need to handle parameters (at least not for passing current version of autobahn test suite). Current version of the specification seem to be kind enough to let the server decide everything, even when it means not accepting any parameter.

Two bugfixes were made - see commit: https://github.com/tyrus-project/tyrus/commit/ce57a321c37f132259e2e8acd0b61ca69f88fdca





[TYRUS-377] Jersey container ? Created: 17/Sep/14  Updated: 27/Nov/14  Resolved: 27/Nov/14

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: icode Assignee: Pavel Bucek
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

How to write a container use Jersey ?



 Comments   
Comment by Pavel Bucek [ 17/Sep/14 ]

firstly - this is not a bug or it even does not look like a improvement request - please use users@tyrus.java.net for general questions like this.

secondly - which container do you mean? Jersey and Tyrus are part of Java EE, so you can use Glassfish and you should be all set to write applications which do use both.

Comment by icode [ 17/Sep/14 ]

Can use jxr-rs ContainerRequestFilter impl handshake ? tyrus => jersey => servlet | netty | grizzly | jetty and more. `=>` is deps

Comment by Pavel Bucek [ 17/Sep/14 ]

you might want to describe your usecase or problem scope in more detail - this is not really understandable.

Anwyay, you cannot use ContainerRequestFilter from JAX-RS to handle WebSocket requests. Once any of these frameworks starts processing the request, it can be passed to the next filter or processed completely (meaning that even if you pass websocket handshake request to jax-rs, it should not invoke container request filters on it when it does not have corresponding JAX-RS resource. And if it does, then the request will be fully processed by JAX-RS/Jersey and not passed to WebSocket/Tyrus).

Comment by Pavel Bucek [ 27/Nov/14 ]

not an issue, just a question. Please use users@tyrus.java.net next time.





[TYRUS-342] Tyrus throw CancellationException Created: 16/Jul/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: tyrus
Component/s: server
Affects Version/s: 1.7
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: dungld Assignee: Pavel Bucek
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 12.04 64bit, java 7 update 51, Glassfish 4.0.1 b8



 Description   

When I run Glassfish server using websocket for pushing data, I got exception from log:

[2014-07-16T14:03:21.883+0700] [glassfish 4.0] [WARNING] [] [org.glassfish.tyrus.servlet.TyrusServletWriter] [tid: _ThreadID=4321 _ThreadName=concurrent/__defaultManagedScheduledExecutorService-managedThreadFactory-Thread-1] [timeMillis: 1405494201883] [levelValue: 900] [[
TyrusServletWriter.onError
java.util.concurrent.CancellationException
at org.glassfish.grizzly.http.io.OutputBuffer$InternalWriteHandler.detach(OutputBuffer.java:1262)
at org.glassfish.grizzly.http.io.OutputBuffer.endRequest(OutputBuffer.java:373)
at org.glassfish.grizzly.http.server.Response.finish(Response.java:516)
at org.glassfish.grizzly.http.server.HttpServerFilter.afterService(HttpServerFilter.java:384)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:290)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.filterchain.FilterChainContext$1.run(FilterChainContext.java:191)
at org.glassfish.grizzly.filterchain.FilterChainContext.resume(FilterChainContext.java:215)
at org.glassfish.grizzly.http.server.Response.resume(Response.java:1923)
at org.apache.catalina.connector.Request.resumeAfterService(Request.java:4451)
at org.apache.catalina.connector.WebConnectionImpl.close(WebConnectionImpl.java:139)
at org.glassfish.tyrus.servlet.TyrusServletWriter.close(TyrusServletWriter.java:173)
at org.glassfish.tyrus.core.ProtocolHandler.doClose(ProtocolHandler.java:399)
at org.glassfish.tyrus.core.TyrusWebSocket.onClose(TyrusWebSocket.java:127)
at org.glassfish.tyrus.core.ProtocolHandler.close(ProtocolHandler.java:295)
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:249)
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:259)
at org.glassfish.tyrus.core.TyrusRemoteEndpoint.close(TyrusRemoteEndpoint.java:466)
at org.glassfish.tyrus.core.TyrusSession.close(TyrusSession.java:227)
at org.glassfish.tyrus.core.TyrusSession$IdleTimeoutCommand.run(TyrusSession.java:721)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$101(ManagedScheduledThreadPoolExecutor.java:383)
at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:532)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)
]]

I dont know what it is and how to fix it.



 Comments   
Comment by Pavel Bucek [ 16/Jul/14 ]

Does this affect you application runtime? (My guess is that it does not).

Seems like Servlet layer invokes WriteListener.onError after (successful) close attempt. Not sure why, will investigate. If you need to get rid of this message in the logs, just disable Logger called "org.glassfish.tyrus.servlet.TyrusServletWriter".

Thanks for your report!

Comment by dungld [ 16/Jul/14 ]

I add more info about this exception (maybe it affect to my app):
check line: at com.gbsofts.gbpriceboard.service.web.BoardDataService.onMessage(BoardDataService.java:124)

[2014-07-16T14:03:21.884+0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=1982 _ThreadName=Thread-9] [timeMillis: 1405494201884] [levelValue: 1000] [[
java.io.IOException: java.util.concurrent.CancellationException
at org.glassfish.tyrus.core.TyrusRemoteEndpoint$Basic.processFuture(TyrusRemoteEndpoint.java:153)
at org.glassfish.tyrus.core.TyrusRemoteEndpoint$Basic.sendText(TyrusRemoteEndpoint.java:96)
at com.gbsofts.gbpriceboard.service.web.BoardDataService.onMessage(BoardDataService.java:124)
at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1081)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1153)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4786)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:656)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:52)
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:608)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCall(SystemInterceptorProxy.java:163)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:140)
at sun.reflect.GeneratedMethodAccessor74.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:883)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:822)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4758)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4746)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:212)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at com.sun.proxy.$Proxy309.onMessage(Unknown Source)
at com.gbsofts.gbpriceboard.service.web._EJB31_GeneratedBoardDataServiceIntf__Bean_.onMessage(Unknown Source)
at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:477)
at org.glassfish.tyrus.core.AnnotatedEndpoint.access$100(AnnotatedEndpoint.java:87)
at org.glassfish.tyrus.core.AnnotatedEndpoint$WholeHandler$1.onMessage(AnnotatedEndpoint.java:573)
at org.glassfish.tyrus.core.TyrusSession.notifyMessageHandlers(TyrusSession.java:520)
at org.glassfish.tyrus.core.TyrusEndpointWrapper.onMessage(TyrusEndpointWrapper.java:745)
at org.glassfish.tyrus.core.TyrusWebSocket.onMessage(TyrusWebSocket.java:200)
at org.glassfish.tyrus.core.frame.TextFrame.respond(TextFrame.java:135)
at org.glassfish.tyrus.core.ProtocolHandler.process(ProtocolHandler.java:612)
at org.glassfish.tyrus.core.TyrusWebSocketEngine$TyrusReadHandler.handle(TyrusWebSocketEngine.java:384)
at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.onDataAvailable(TyrusHttpUpgradeHandler.java:164)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.processDataAvailable(InputBuffer.java:488)
at org.apache.catalina.connector.InputBuffer$ReadHandlerImpl.onDataAvailable(InputBuffer.java:453)
at org.glassfish.grizzly.http.io.InputBuffer.invokeHandler(InputBuffer.java:1101)
at org.glassfish.grizzly.http.io.InputBuffer.invokeHandlerOnProperThread(InputBuffer.java:1092)
at org.glassfish.grizzly.http.io.InputBuffer.append(InputBuffer.java:975)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:271)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.util.concurrent.CancellationException
at org.glassfish.grizzly.http.io.OutputBuffer$InternalWriteHandler.detach(OutputBuffer.java:1262)
at org.glassfish.grizzly.http.io.OutputBuffer.endRequest(OutputBuffer.java:373)
at org.glassfish.grizzly.http.server.Response.finish(Response.java:516)
at org.glassfish.grizzly.http.server.HttpServerFilter.afterService(HttpServerFilter.java:384)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:290)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.filterchain.FilterChainContext$1.run(FilterChainContext.java:191)
at org.glassfish.grizzly.filterchain.FilterChainContext.resume(FilterChainContext.java:215)
at org.glassfish.grizzly.http.server.Response.resume(Response.java:1923)
at org.apache.catalina.connector.Request.resumeAfterService(Request.java:4451)
at org.apache.catalina.connector.WebConnectionImpl.close(WebConnectionImpl.java:139)
at org.glassfish.tyrus.servlet.TyrusServletWriter.close(TyrusServletWriter.java:173)
at org.glassfish.tyrus.core.ProtocolHandler.doClose(ProtocolHandler.java:399)
at org.glassfish.tyrus.core.TyrusWebSocket.onClose(TyrusWebSocket.java:127)
at org.glassfish.tyrus.core.ProtocolHandler.close(ProtocolHandler.java:295)
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:249)
at org.glassfish.tyrus.core.TyrusWebSocket.close(TyrusWebSocket.java:259)
at org.glassfish.tyrus.core.TyrusRemoteEndpoint.close(TyrusRemoteEndpoint.java:466)
at org.glassfish.tyrus.core.TyrusSession.close(TyrusSession.java:227)
at org.glassfish.tyrus.core.TyrusSession$IdleTimeoutCommand.run]]

[2014-07-16T14:03:21.884+0700] [glassfish 4.0] [SEVERE] [] [] [tid: _ThreadID=1982 _ThreadName=Thread-9] [timeMillis: 1405494201884] [levelValue: 1000] [[
(TyrusSession.java:721)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)
at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$101(ManagedScheduledThreadPoolExecutor.java:383)
at org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:532)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)]]

Comment by Pavel Bucek [ 16/Jul/14 ]

that seems to be ok - you are sending a message and the connection is closed in the process for some reason - so the send method will throw an exception, because the message was not sent.

Comment by Pavel Bucek [ 11/Nov/14 ]

This should not happen any more.

TyrusServletWriter#close should not throw any exception ever (and it is like this from 13/4/2013, so you might want to check your server-side Tyrus version).

Feel free to reopen, ideally with a testcase; thanks!





[TYRUS-379] Autobahn testcases 7.3.4 & 7.3.5 fail in close stage Created: 17/Sep/14  Updated: 11/Nov/14  Resolved: 11/Nov/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.9
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Pavel Bucek [ 11/Nov/14 ]

this was caused by regression in autobahn test suite: https://github.com/tavendo/AutobahnPython/issues/249





[TYRUS-385] Session idle timeout concurrency issues Created: 03/Oct/14  Updated: 10/Nov/14  Resolved: 10/Nov/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.8.3, 1.9
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

@OnClose (or Endpoint.onClose(...)) can be called sooner from underlying transport than from idle timeout handler, which causes @OnClose invocation with close code 1000 instead 1006.



 Comments   
Comment by Pavel Bucek [ 10/Nov/14 ]

commit aa4ca04f55bb7a97935757d5bcfb4a3363370e5f
Author: Pavel Bucek <pavel.bucek@oracle.com>
Date: Mon Nov 10 17:19:08 2014 +0100

TYRUS-385: Session idle timeout concurrency issues.

Added synchronization to TyrusWebSocket, which should ensure the ordering of onClose(...) invocations,
when the IdletimeoutCommand is envolved.





[TYRUS-389] Support SSL configuration in standalone server Created: 17/Oct/14  Updated: 17/Oct/14

Status: Open
Project: tyrus
Component/s: server
Affects Version/s: 1.8.3
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: isart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The idea is being able to configure SSL in a standalone server similarly as it can be done to the client:
https://tyrus.java.net/documentation/1.8.3/user-guide.html#d0e1128

Probably by passing to the server the same SslEngineConfigurator with an SslContextConfigurator that is supported in the client.



 Comments   
Comment by isart [ 17/Oct/14 ]

Currently SSLEngine can be influenced by setting appropriated System properties:
System.setProperty(SslContextConfigurator.KEY_STORE_FILE, keystorePath);
System.setProperty(SslContextConfigurator.KEY_STORE_PASSWORD, keystorePassword);
...

However, using JVM global properties may not be appropriated in several scenarios.





[TYRUS-388] Support WSS in standalone server Created: 17/Oct/14  Updated: 17/Oct/14

Status: Open
Project: tyrus
Component/s: server
Affects Version/s: 1.8.3
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: isart Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As a developer, I'd like to be able to enable WSS programmatically in a standalone server.

Currently (version 1.8.3) one has to apply following hack in order to do it:
https://java.net/projects/tyrus/lists/users/archive/2014-02/message/1






[TYRUS-380] setContextClassLoader throws "access denied" exception in JNLP client app Created: 19/Sep/14  Updated: 29/Sep/14  Resolved: 23/Sep/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.8.3
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: cemartins Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:
ThreadPoolConfig workerThreadPoolConfig = ThreadPoolConfig.defaultConfig();
		workerThreadPoolConfig.setInitialClassLoader(this.getClass().getClassLoader());
workerThreadPoolConfig.setDaemon(false);
workerThreadPoolConfig.setMaxPoolSize(4);
workerThreadPoolConfig.setCorePoolSize(3);
client = ClientManager.createClient(JdkClientContainer.class.getName());
client.getProperties().put(ClientProperties.RECONNECT_HANDLER, reconnectHandler);
client.getProperties().put(ClientProperties.SHARED_CONTAINER, false);
client.getProperties().put(ClientProperties.WORKER_THREAD_POOL_CONFIG, workerThreadPoolConfig);


 Description   

Class TransportFilter$TransportThreadFactory line #344 and #346, the call to setContextClassLoader throws "access denied" exception when the Client manager is started by an application started by java web start (jnlp).
The app is signed and the jnlp file has an "all-permissions" security parameter.

I think a solution could be to execute this method inside a java.security.PrivilegedExceptionAction like so:

try {
	AccessController.doPrivileged(new PrivilegedExceptionAction<Void>() {
		
		public Void run() throws JAXBException {

			if (threadPoolConfig.getInitialClassLoader() == null) {
				thread.setContextClassLoader(this.getClass().getClassLoader());
			} else {
				thread.setContextClassLoader(threadPoolConfig.getInitialClassLoader());
			}
			
			return null;
	    }
	});
} catch (PrivilegedActionException e) {
	throw new SomeTyrusWrapperException(e);
}			


 Comments   
Comment by Pavel Bucek [ 19/Sep/14 ]

Thanks for filing this issue!

I'm just curious - have you tried the fix you suggested? Also, was this the only error which prevented Tyrus client (on jdk container) to run in jnlp?

Comment by cemartins [ 19/Sep/14 ]

I haven't tried this fix. My forked tyrus workspace has many errors and I am a bit tied up with other issues at work at the moment.

I had a previous error (in the same jnlp client app) with an Encoder to marshall an object into XML throwing the same "access denied" exception while doing introspection. The encoder was also running on a tyrus thread.
I resolved that problem with the proposed fix.

Comment by cemartins [ 19/Sep/14 ]

I finally managed to dedicate some more time to this issue.
I cloned the repo and created a branch called TYRUS-380. then I run all tests in this branch before and after coding in my suggested fix. All tests OK:

Tests run: 10, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] tyrus ............................................. SUCCESS [0.002s]
[INFO] tyrus-archetypes .................................. SUCCESS [0.001s]
[INFO] Tyrus Echo Archetype .............................. SUCCESS [0.443s]
[INFO] Tyrus BOM ......................................... SUCCESS [0.000s]
[INFO] Tyrus Container SPI ............................... SUCCESS [0.885s]
[INFO] Tyrus Core ........................................ SUCCESS [3.037s]
[INFO] Tyrus Client ...................................... SUCCESS [0.741s]
[INFO] Tyrus Container Modules ........................... SUCCESS [0.000s]
[INFO] Tyrus Containers For Glassfish .................... SUCCESS [0.000s]
[INFO] Tyrus CDI Component Provider ...................... SUCCESS [0.082s]
[INFO] Tyrus EJB Component Provider ...................... SUCCESS [0.078s]
[INFO] Tyrus Grizzly Client Container .................... SUCCESS [0.235s]
[INFO] Tyrus Server ...................................... SUCCESS [0.435s]
[INFO] Tyrus Grizzly Server Container .................... SUCCESS [0.129s]
[INFO] Tyrus InMemory Container .......................... SUCCESS [0.486s]
[INFO] Tyrus Servlet Bundle .............................. SUCCESS [0.116s]
[INFO] Tyrus Tests ....................................... SUCCESS [0.000s]
[INFO] Tyrus Test Tools .................................. SUCCESS [0.035s]
[INFO] Tyrus JDK Client Container ........................ SUCCESS [8.839s]
[INFO] Tyrus Documentation ............................... SUCCESS [0.039s]
[INFO] Tyrus Extension Modules ........................... SUCCESS [0.001s]
[INFO] Tyrus CLI Client .................................. SUCCESS [0.066s]
[INFO] Tyrus Monitoring JMX .............................. SUCCESS [1.448s]
[INFO] Tyrus Extension - Per Message Deflate ............. SUCCESS [0.802s]
[INFO] Tyrus Samples ..................................... SUCCESS [0.001s]
[INFO] Tyrus Auction Sample .............................. SUCCESS [0.032s]
[INFO] Tyrus CDI Sample .................................. SUCCESS [0.344s]
[INFO] Tyrus Chat Sample ................................. SUCCESS [0.011s]
[INFO] Tyrus Draw Sample ................................. SUCCESS [0.007s]
[INFO] Tyrus Echo Sample ................................. SUCCESS [0.743s]
[INFO] Tyrus Basic Auth Sample ........................... SUCCESS [0.291s]
[INFO] Tyrus Dart Echo Sample ............................ SUCCESS [0.814s]
[INFO] Tyrus Secure Echo Sample .......................... SUCCESS [0.025s]
[INFO] Tyrus Programmatic Echo Sample .................... SUCCESS [0.797s]
[INFO] Tyrus Simple Life Sample .......................... SUCCESS [0.011s]
[INFO] Tyrus End-to-End Tests ............................ SUCCESS [0.000s]
[INFO] Tyrus End-to-End Application Config Tests ......... SUCCESS [2.430s]
[INFO] Tyrus End-to-End Non-deployable Tests ............. SUCCESS [8.749s]
[INFO] Tyrus End-to-End Standard Config Tests ............ SUCCESS [1:10.292s]
[INFO] Tyrus End-to-End Java 8 Tests ..................... SUCCESS [0.758s]
[INFO] Tyrus End-to-End Tests running on Jetty ........... SUCCESS [0.000s]
[INFO] Tyrus End-to-End Basic Auth Tests ................. SUCCESS [2.923s]
[INFO] Tyrus End-to-End Digest Auth Tests ................ SUCCESS [1.704s]
[INFO] Tyrus Server Integration Tests .................... SUCCESS [0.000s]
[INFO] Tyrus Servlet Async Tests ......................... SUCCESS [1.021s]
[INFO] Tyrus Autobahn Echo Server ........................ SUCCESS [0.015s]
[INFO] Tyrus Servlet Basic Tests ......................... SUCCESS [14.540s]
[INFO] Tyrus Servlet Dynamic Deploy Test ................. SUCCESS [0.277s]
[INFO] Tyrus Servlet No App Config ....................... SUCCESS [0.771s]
[INFO] Tyrus Servlet One App Config ...................... SUCCESS [0.803s]
[INFO] Tyrus Servlet RemoteEndpoint Timeout .............. SUCCESS [0.298s]
[INFO] Tyrus Servlet Session Closing ..................... SUCCESS [16.851s]
[INFO] Tyrus Servlet Two App Config ...................... SUCCESS [0.803s]
[INFO] Tyrus Servlet Monitoring Test ..................... SUCCESS [0.826s]
[INFO] Tyrus Servlet Inject Test ......................... SUCCESS [0.274s]
[INFO] Tyrus Servlet Max Sessions Per App Tests .......... SUCCESS [2.393s]
[INFO] Tyrus Servlet Max Sessions Per Remote Addr Tests .. SUCCESS [2.491s]
[INFO] Tyrus Debug Debug Samples ......................... SUCCESS [11.004s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:41.091s
[INFO] Finished at: Fri Sep 19

I can create a pull request, if you'd like.

Comment by Pavel Bucek [ 23/Sep/14 ]

that's fine, thanks.

I created something very similar to yours (I'm not explicitly throwing JAXB related exception...): https://github.com/tyrus-project/tyrus/pull/162

Comment by cemartins [ 23/Sep/14 ]

Correct. That JAXB exception should not be there. it was a Copy/paste thing

Comment by Pavel Bucek [ 23/Sep/14 ]

pull request was merged to the master branch. Thanks for your evaluation!

Comment by cemartins [ 29/Sep/14 ]

Any ideas as to when version 1.9 will be released?

Comment by Pavel Bucek [ 29/Sep/14 ]

most likely in 2-3 weeks





[TYRUS-383] session.getRequestParameterMap does not contain query parameters when running on Grizzly standalone server Created: 20/Sep/14  Updated: 23/Sep/14  Resolved: 23/Sep/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.9
Fix Version/s: 1.9

Type: Bug Priority: Minor
Reporter: icode Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

not have API to get query params? getRequestParameterMap return path params



 Comments   
Comment by Pavel Bucek [ 20/Sep/14 ]

please use users@tyrus.java.net fro questions.

Session.getRequestParameterMap returns what is in ServletRequest.getParameterMap().

Comment by icode [ 20/Sep/14 ]

but email group not reply. MessageHandler is thread safe it?

Comment by icode [ 20/Sep/14 ]

I get http://localhost/ws?q=1

session.getRequestParameterMap return empty

Comment by Pavel Bucek [ 20/Sep/14 ]

you need to subscribe to recieve the responses.

I replied to your question in less than a hour, see https://java.net/projects/tyrus/lists/users/archive/2014-09/message/10. Please don't abuse our bug tracking system..

Comment by Pavel Bucek [ 22/Sep/14 ]

reopened, reporter shared more details on the mailing list.

Comment by Pavel Bucek [ 23/Sep/14 ]

fix merged to the master branch





[TYRUS-382] onError parameter exception is wrapped in InvocationTargetException when an exception is thrown from programmatic endpoint (onOpen or onClose) Created: 20/Sep/14  Updated: 23/Sep/14  Resolved: 23/Sep/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: icode Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

onError throwable not original exception at onOpen method

public void onOpen(final Session session, final EndpointConfig config)

{ throw new WebSocketExcption(); }

public void onError(Session session, Throwable thr)

{ //get a InvocationTargetException }

at TyrusEndpointWrapper class and method is Session onConnect(TyrusWebSocket socket, UpgradeRequest upgradeRequest, String subProtocol, List<Extension> extensions, String connectionId, DebugContext debugContext)

please add exception restore

...
} catch (Throwable t) {
if (thr instanceof InvocationTargetException)

{ thr = thr.getCause(); }

if (endpoint != null) {...



 Comments   
Comment by Pavel Bucek [ 20/Sep/14 ]

adjusted the title.

the issue is related only to programmatic endpoints and affect onOpen and onClose methods.

Comment by Pavel Bucek [ 20/Sep/14 ]

pull request with the proposed fix: https://github.com/tyrus-project/tyrus/pull/159

Comment by Pavel Bucek [ 23/Sep/14 ]

fix merged to the master branch





[TYRUS-381] exception message error Created: 19/Sep/14  Updated: 23/Sep/14  Resolved: 23/Sep/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.9
Fix Version/s: 1.9

Type: Bug Priority: Major
Reporter: icode Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

MessageHandler for type: class parity.account.resources.AccountResource already registered.

at MessageHandlerManager,

org.glassfish.tyrus.core.MessageHandlerManager.addMessageHandler(MessageHandlerManager.java:203) ~[tyrus-core-1.8.3.jar:na]

message error , should be invalid type, because not has decoder?



 Comments   
Comment by Pavel Bucek [ 19/Sep/14 ]

Can you please share the sample code which reproduces the issue you are mentioning?

Comment by icode [ 19/Sep/14 ]

add a not have decoder whole message handler pls

Comment by icode [ 19/Sep/14 ]

session.addMessageHandler(new MessageHandler.Whole<Account>() {
@Override
public void onMessage(Account message)

{ endpoint.sendText("1. rec msg:" + message); }

})

Comment by icode [ 19/Sep/14 ]

pls see public <T> void addMessageHandler(Class<T> clazz, MessageHandler.Partial<T> handler)

if (!viable)

{ throwException(LocalizationMessages.MESSAGE_HANDLER_PARTIAL_INVALID_TYPE(clazz.getName())); }

at org.glassfish.tyrus.core.MessageHandlerManager.addMessageHandler(MessageHandlerManager.java:203) ~[tyrus-core-1.8.3.jar:na] this message is error, should be MESSAGE_HANDLER_WHOLE_INVALID_TYPE

Comment by Pavel Bucek [ 19/Sep/14 ]

If you can, please check whether following fixes your issue: http://github.com/tyrus-project/tyrus/pull/158

(it should. It changes the message to different one, your suggestion was not correct).

Thanks,
Pavel

Comment by icode [ 19/Sep/14 ]

yes, i say ` invalid type` because add `Partial Message Handler` is throw `LocalizationMessages.MESSAGE_HANDLER_PARTIAL_INVALID_TYPE` excption message, so add `Partial Message Handler` message was not correct! please consistent error message

Comment by Pavel Bucek [ 19/Sep/14 ]

Problem is that you cannot really register partial message handler with decoder, so "invalid type" message is ok there, since there is only limited set of possible types.

On the other hand, for messageHandler.Whole, you can register a custom type which does have a decoder, so error message "decoder for type XXX was not found." seems much better to me. Meaning that we cannot really "be consistent" in slightly different use cases..

Comment by icode [ 19/Sep/14 ]

Ok,that's all right.Partial message can not use for decoder?

Comment by icode [ 19/Sep/14 ]

Ok, seem like this. WebSocket Java API not be consistent."ignoring the remaining decoders."

Comment by icode [ 19/Sep/14 ]

this issue fixed.

Comment by Pavel Bucek [ 23/Sep/14 ]

fix merged to the master branch





[TYRUS-384] Call ClientEngine#processError properly from client Created: 22/Sep/14  Updated: 22/Sep/14

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Ondrej Kosatka Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are still some piece of code where client attempt to connect failing and ClientEngine#processError should be called to invoke ClientHandshakeListener#onError and it does not.



 Comments   
Comment by Ondrej Kosatka [ 22/Sep/14 ]

https://github.com/okosatka/tyrus/tree/tyrus-384

Comment by Ondrej Kosatka [ 22/Sep/14 ]

Fixed: When connecting to proxy fails then CleintEngine#processError is called form both client implementations.





[TYRUS-376] Investigate how/whether is ScheduledExecutorService terminated when session is closed (related to heart beat feature) Created: 11/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.9
Fix Version/s: 1.9

Type: Task Priority: Major
Reporter: Pavel Bucek Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

based on user report from mailing list:

https://java.net/projects/tyrus/lists/users/archive/2014-09/message/4






[TYRUS-375] Buffer overflow during HTTP Response size parsing (jdk client container) Created: 10/Sep/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8.2
Fix Version/s: 1.9

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

ClientFilter: 148

    @Override
    public boolean processRead(ByteBuffer data) {
        if (wsConnection == null) {

            // TODO: refactor appendData to throw ParseException and react accordingly when thrown.
            responseParser.appendData(data);





[TYRUS-378] Revise logged errors in client containers Created: 17/Sep/14  Updated: 17/Sep/14

Status: Open
Project: tyrus
Component/s: client
Affects Version/s: 1.8.3
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: petrjanouch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Because of lack of an error handling method in client SPI, some errors in client containers were just logged. Revise errors logged in client containers and consider use of processError method from client SPI.






[TYRUS-371] Introduce an option for using custom masking key generator. Created: 02/Sep/14  Updated: 16/Sep/14  Resolved: 16/Sep/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.8.2
Fix Version/s: 1.9

Type: Improvement Priority: Major
Reporter: petrjanouch Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

By default masking keys are generated using SecureRandom, which in its internals uses a synchronized singleton as a random entropy provider. While this is OK for usual Tyrus client use cases, it might prove to be a performance issue, when the client is used for instance for highly parallel stress testing.






[TYRUS-368] Instantiate default encoders and decoders once per endpoint Created: 01/Sep/14  Updated: 11/Sep/14  Resolved: 03/Sep/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.8.2
Fix Version/s: 1.8.3, 1.9

Type: Improvement Priority: Major
Reporter: Ondrej Kosatka Assignee: Ondrej Kosatka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-369] Format localized messages when necessary Created: 02/Sep/14  Updated: 11/Sep/14  Resolved: 03/Sep/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.8.2
Fix Version/s: 1.8.3, 1.9

Type: Improvement Priority: Major
Reporter: Ondrej Kosatka Assignee: Ondrej Kosatka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-285] Improve broadcast by sending from multiple (configurable) threads. Created: 18/Dec/13  Updated: 11/Sep/14  Resolved: 11/Sep/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.8.3, 1.9

Type: New Feature Priority: Major
Reporter: Pavel Bucek Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-365] Broadcast messages are not included in the monitoring statistics Created: 28/Aug/14  Updated: 11/Sep/14  Resolved: 01/Sep/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.8.2
Fix Version/s: 1.8.3, 1.9

Type: Bug Priority: Major
Reporter: petrjanouch Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-370] Masking key is generated on server side Created: 02/Sep/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.8.2
Fix Version/s: 1.8.3, 1.9

Type: Bug Priority: Major
Reporter: petrjanouch Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Masking key is generated for each sent frame on both server and client side. If the frame is sent from a server, the masking key is just not used. Generating masking key is an expensive operation and should not be done on the server side.






[TYRUS-289] Introduce DEBUG mode (client/server) Created: 09/Jan/14  Updated: 11/Sep/14  Resolved: 11/Sep/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: None
Fix Version/s: 1.8.3, 1.9

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-366] master branch not buildable with JDK 1.6 Created: 28/Aug/14  Updated: 11/Sep/14  Resolved: 01/Sep/14

Status: Resolved
Project: tyrus
Component/s: None
Affects Version/s: 1.8, 1.8.1, 1.8.2
Fix Version/s: 1.8.3, 1.9

Type: Bug Priority: Major
Reporter: Pavel Bucek Assignee: Ondrej Kosatka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-304] Review ByteBuffer reading when sending/receiving messages (using RemoteEndpoint.sendBinary( ... )) Created: 13/Mar/14  Updated: 03/Sep/14

Status: Open
Project: tyrus
Component/s: core
Affects Version/s: 1.5
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-372] Revise Match class Created: 03/Sep/14  Updated: 03/Sep/14

Status: Open
Project: tyrus
Component/s: core
Affects Version/s: 1.8.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: petrjanouch Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Match class contains methods that are used only in tests. Move such methods directly to the tests or investigate if the tests using those methods could not be rewritten to use Tyrus directly.






[TYRUS-367] Provide a way how to get low-level info about the session. Created: 29/Aug/14  Updated: 02/Sep/14

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: 1.8
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: Ondrej Kosatka
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Something similar to what ServletRequest [1] provides:

java.lang.String getLocalAddr()
java.lang.String getLocalHost()
int getLocalPort()
java.lang.String getRemoteAddr()
java.lang.String getRemoteHost()
int getRemotePort()

[1] http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html






[TYRUS-307] Revise ignored tests Created: 18/Mar/14  Updated: 01/Sep/14  Resolved: 01/Sep/14

Status: Resolved
Project: tyrus
Component/s: tests
Affects Version/s: None
Fix Version/s: 1.9

Type: Improvement Priority: Minor
Reporter: petrjanouch Assignee: Ondrej Kosatka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Pavel Bucek [ 11/Aug/14 ]

+ move tests from non_deployable to standard/application tests when possible.





[TYRUS-358] ClientEndpointConfig.Configurator only get first HTTP header with same name Created: 01/Aug/14  Updated: 01/Sep/14  Resolved: 01/Sep/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.7
Fix Version/s: 1.8.1

Type: Bug Priority: Minor
Reporter: andreas.jansson@oracle.com Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

When using tyrus + grizzly the afterResponse(...) method in ClientEndpointConfig.Configurator will only recieve the first HTTP header when there are multiple headers with the same name.

The bug seems to be in org.glassfish.tyrus.container.grizzly.client.GrizzlyClientFilter class in the getUpgradeResponse(...) method since.

This was tested using tyrus-standalone-client 1.7.






[TYRUS-363] Allow more dynamic Credentials in Authenticator Created: 14/Aug/14  Updated: 25/Aug/14  Resolved: 25/Aug/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8
Fix Version/s: 1.8

Type: Improvement Priority: Minor
Reporter: PieterJan_Pintens Assignee: Pavel Bucek
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all



 Description   

User story:
As a developper
I want to use more customized and extensive credentials in the Authencticator
So i can make user of advanced authentication frameworks like oauth

In detail:
We are using the library in our product, it works very great.
We were very happy to see support for custom authentication, as we are currently working on that too. The only limitation we came across was that the Credentials class is to limited. It works for Basic but our more advanced OAuth setup simply needs more fields than username and password. The question is simple: Would it be possible to provide an interface instead of a final class? Or just a class that is not final so we can wrap our credentials our provide custom ones?

We can work around the problem but in our opinion it seems a bit harsh to limit the credentials like that.



 Comments   
Comment by Pavel Bucek [ 14/Aug/14 ]

You don't need to use the Credentials class from Tyrus when you register custom Authenticator.

All you need is to pass that info directly to your authenticator in any format you want. Authenticator#generateAuthorizationHeader will be then called with "null" as value of Credentials parameter, but the rest of the functionality will still work as expected.

I consider this solution better to just make an interface from existing Credentials class - you would need to do "ugly" instanceof check and type cast..

Comment by PieterJan_Pintens [ 14/Aug/14 ]

Ok that is another option. Thank you for the update. We will use that method instead.





[TYRUS-360] Add client support for Http status 503 with retry-after header Created: 05/Aug/14  Updated: 25/Aug/14  Resolved: 25/Aug/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8
Fix Version/s: 1.8, 1.8.1, 1.8.2

Type: Improvement Priority: Major
Reporter: Pavel Bucek Assignee: Ondrej Kosatka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-362] Revise userdoc Created: 12/Aug/14  Updated: 12/Aug/14

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Pavel Bucek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
  • add entities/links to javadoc
  • unify formatting across whole document





[TYRUS-355] HTTP Redirect - Location header cannot be a relative address Created: 30/Jul/14  Updated: 12/Aug/14  Resolved: 06/Aug/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8
Fix Version/s: 1.8.1, 1.9

Type: Bug Priority: Minor
Reporter: Ondrej Kosatka Assignee: Ondrej Kosatka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tyrus handshake process should support relative path in Location header in 3xx HTTP Redirect response according to the rules defined in http://tools.ietf.org/html/rfc3986#section-5



 Comments   
Comment by Ondrej Kosatka [ 06/Aug/14 ]

Normalized location header is now resolved against last requested URI so we always get absolute URI.

commit - 0534eda7b0aece4e180c0bde8bb6d247e78b05ff





[TYRUS-359] Client based on Java 7 Asynchronous IO makes application unexitable Created: 02/Aug/14  Updated: 10/Aug/14  Resolved: 03/Aug/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.7
Fix Version/s: 1.8

Type: Bug Priority: Major
Reporter: martinandersson.com Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Standalone JavaFX application, tested on both Windows 7 and Windows 8.1.



 Description   

I used to have this depedency in my standalone front-end application:

<dependency>
<groupId>org.glassfish.tyrus.bundles</groupId>
<artifactId>tyrus-standalone-client</artifactId>
<version>1.7</version>
<scope>compile</scope>
</dependency>

After having opened the WebSocket, the application exists normally. However, I tried the newish "JDK" Tyrus client:

<dependency>
<groupId>org.glassfish.tyrus.bundles</groupId>
<artifactId>tyrus-standalone-client-jdk</artifactId>
<version>1.7</version>
<scope>compile</scope>
</dependency>

Now my application doesn't close normally anymore after having closed the last window. It appears to me that the JDK client has created non-daemon threads?



 Comments   
Comment by Pavel Bucek [ 02/Aug/14 ]

Can you please re-try with 1.8-SNAPSHOT? (available on java.net snaptshots repo: https://maven.java.net/content/repositories/snapshots)

We changed a lot in JDK 7 NIO client implementation and this might be already fixed. Thanks!

Comment by martinandersson.com [ 03/Aug/14 ]

Tried using 1.8-SNAPSHOT and I can confirm that this release solve the problem, thank you so much! The problem is only present in 1.7 and probably in earlier versions too as far as I can tell.

Comment by Pavel Bucek [ 03/Aug/14 ]

great, thanks for verification! Closing this as already fixed.

Comment by martinandersson.com [ 09/Aug/14 ]

Actually, the issue was not fixed, only for the situation where I had not first opened a websocket. If I open a websocket (make contact with the back-end server), the problem persist making my application unexitable.

To be absolutely clear: Not using the JDK client makes my application exit when he's supposed to: when the last thread die. The JDK client prior to 1.8-SNAPSHOT didn't let my application exit but continued work in the background independent of whether or not my application had opened a websocket to the back-end server. 1.8-SNAPSHOT solved half the problem; the application did exit only if didn't make a connection to the server. But if I do, we're back at square one and my application won't quit.

Comment by martinandersson.com [ 10/Aug/14 ]

Okay I can confirm it works in 1.9-SNAPSHOT.





[TYRUS-341] A control frame inside a stream of continuation frames is treated as the part of the stream Created: 11/Jul/14  Updated: 05/Aug/14  Resolved: 05/Aug/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.7
Fix Version/s: 1.8

Type: Bug Priority: Major
Reporter: petrjanouch Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

For instance when a pong or close message is sent while a text or binary partial messages are being sent, it is treated as part of the partial messages stream.






[TYRUS-330] create/run tests/servlet/basic via wss Created: 16/Jun/14  Updated: 05/Aug/14  Resolved: 05/Aug/14

Status: Resolved
Project: tyrus
Component/s: tests
Affects Version/s: None
Fix Version/s: 1.8

Type: Task Priority: Major
Reporter: Pavel Bucek Assignee: petrjanouch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified





[TYRUS-357] Exception thrown in MessageHandler#OnMessage is not caught in @OnError method Created: 01/Aug/14  Updated: 01/Aug/14  Resolved: 01/Aug/14

Status: Resolved
Project: tyrus
Component/s: core
Affects Version/s: 1.7
Fix Version/s: 1.8

Type: Bug Priority: Major
Reporter: jan.supol Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Suppose a MessageHandler:

public class PongMessageHandler implements MessageHandler.Whole<PongMessage> {

    protected Session session;
    public static final String HANDLER_SAYS = "Handler message";

    public PongMessageHandler(Session session) {
        this.session = session;
    }

    @Override
    public void onMessage(PongMessage pong) {
         try {
            session.getBasicRemote().sendText(HANDLER_SAYS);
        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }
} 

And an Endpoint:

@ServerEndpoint("/exception")
public class WSCAnnotatedMixedServerEndpoint {

    public static final String EXCEPTION = "Exception: ";
    static class PongMessageThrowingMessageHandler extends PongMessageHandler {
        public PongMessageThrowingMessageHandler(Session session) {
            super(session);
        }

        @Override
        public void onMessage(PongMessage message) {
            session.addMessageHandler(PongMessage.class, this); //throws runtime exception
        }
    }

    @OnOpen
    public void onOpen(Session session) {
        session.addMessageHandler(PongMessage.class,
                new PongMessageThrowingMessageHandler(session));
    }

    @OnError
    public void onError(Session session, Throwable t) throws IOException {
        String message = EXCEPTION + t.getMessage();
        session.getBasicRemote().sendText(message);
    }
} 

RuntimeException is thrown, but it is not propagated into @OnError



 Comments   
Comment by Pavel Bucek [ 01/Aug/14 ]

fix merged to the master branch (rev 02761d55b9b82878a430abea98e7858af15f53c3)





[TYRUS-356] Tyrus cannot determine the connection port for a wss URL Created: 01/Aug/14  Updated: 01/Aug/14  Resolved: 01/Aug/14

Status: Resolved
Project: tyrus
Component/s: client
Affects Version/s: 1.8
Fix Version/s: 1.8

Type: Bug Priority: Critical
Reporter: jewel-sea Assignee: Pavel Bucek
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS 6.5, Java 8b11, Tyrus 1.8-SNAPSHOT, Grizzy client container



 Description   

When trying to connect to an address using the wss:// protocol without explicitly providing a port, the connection port cannot be determined.

Stack Trace:

javax.websocket.DeploymentException: port out of range:-1
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:352)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.access$000(GrizzlyClientSocket.java:104)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:235)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:230)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.connect(GrizzlyClientSocket.java:259)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer.openClientSocket(GrizzlyClientContainer.java:101)
at org.glassfish.tyrus.client.ClientManager$1$1.run(ClientManager.java:559)
at org.glassfish.tyrus.client.ClientManager$1.run(ClientManager.java:610)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalArgumentException: port out of range:-1
at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
at java.net.InetSocketAddress.<init>(InetSocketAddress.java:224)
at org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:350)
... 12 more

On reviewing the code, GrizzlyClientSocket.java fails for the following call, because upgradeRequest.getRequestURI().getPort() is returning -1, which leads to an invalid InetSocketAddress:

case DIRECT:
connectAddress = new InetSocketAddress(upgradeRequest.getRequestURI().getHost(), upgradeRequest.getRequestURI().getPort());
} catch (IllegalArgumentException e)

{ throw new DeploymentException(e.getMessage(), e); }

This error was found when testing against a recent 1.8-SNAPSHOT (the error was not encountered with 1.7).



 Comments   
Comment by Pavel Bucek [ 01/Aug/14 ]

fix merged to master branch (rev f2beaaedcb23e91e348f038f244f9e62bf6054a7)





[TYRUS-348] When a client and server close connection simultaneously, JDK client throws NPE Created: 25/Jul/14  Updated: 31/Jul/14  Resolved: 31/Jul/14

Status: Resolved
Project: