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

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

Type: Bug Priority: Blocker
Reporter: andrejbal Assignee: Unassigned
Resolution: Unresolved 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?






[TYRUS-94] ServerEndPoint: onError(): throwable.getCause()==null Created: 14/Feb/13  Updated: 27/Jun/13

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: 1.0-b12
Fix Version/s: 1.x-backlog

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

uname -a
Linux mikc 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux



 Description   

I'm getting NPE in the following code. In the onClose() method I send a message, however the socket is already closed, this will raise the onError() method which is fine, however when I want to determine the cause via Throwable.getCause() I get null pointer. It would be handy if we can somehow determine what happened.

public class ProgrammaticServer extends Endpoint {

    private static final Logger logger = Logger.getLogger(ProgrammaticServer.class.getCanonicalName());
    BasicTextMessageHandler mh;
    

    @Override
    public void onOpen(Session s, EndpointConfiguration ec) {
        logger.log(Level.INFO, "Someone connected:{0}", s.getRequestURI().toString());
        mh = ((ProgrammaticServerConfiguration)ec).getMessageHandler("messageHandler");
        mh.setSession(s);
        s.addMessageHandler(mh);
    }


    @Override
    public void onClose(Session s, CloseReason reason) {
        logger.log(Level.INFO, "Clossing the session: {0}", s.toString());
        final RemoteEndpoint remote = s.getRemote();
        try {
            
            
            if(!reason.getCloseCode().equals(CloseReason.CloseCodes.GOING_AWAY)) {
                throw new RuntimeException("CloseReason.CloseCode should be GOING_AWAY");
            }
            //should raise on error
            remote.sendString("Raise onError now - socket is closed");
            s.close();
        } catch (IOException ex) {
            logger.log(Level.SEVERE, null, ex);
        }
    }

    @Override
    public void onError(Session s, Throwable thr) {
        logger.log(Level.SEVERE, "onError: {0}", thr.getLocalizedMessage());
        logger.log(Level.SEVERE, "onError: {0}", thr.getMessage());
        logger.log(Level.SEVERE, "onError: cause: {0}", thr.getCause().getMessage());
        final RemoteEndpoint remote = s.getRemote();
        try {
            remote.sendString("onError");
        } catch (IOException ex) {
            logger.log(Level.SEVERE, null, ex);
        }
    }
}


 Comments   
Comment by mikc22 [ 27/Feb/13 ]

If the user thows the exception (e.g. in onClose method) the behavior differs in the programmatic and annotated case. In the annotated case the user doesn't get the exceptions as-is (unlike in Programmatic case) and it's wrapped in java.lang.reflect.InvocationTargetException, see the following execption example and the comparison to the programmatic case.

cd tyrus~source-code-repository/trunk/tests/qa/websockets-lifecycle-test && mvn -Dtest=LifeCycleTest#testLifeCycleAnnotated clean test

Annotated:
java.lang.reflect.InvocationTargetException
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.onClose(AnnotatedEndpoint.java:448)
...snip...
Caused by: java.lang.RuntimeException: going onError
at org.glassfish.tyrus.tests.qa.lifecycle.SessionLifeCycle.onServerClose(SessionLifeCycle.java:87)
at org.glassfish.tyrus.tests.qa.lifecycle.handlers.text.AnnotatedStringSession$Server.onClose(AnnotatedStringSession.java:87)
... 27 more

Programmatic
cd tyrus~source-code-repository/trunk/tests/qa/websockets-lifecycle-test && mvn -Dtest=LifeCycleTest#testLifeCyeProgrammatic clean test
java.lang.RuntimeException: going onError
at org.glassfish.tyrus.tests.qa.lifecycle.SessionLifeCycle.onServerClose(SessionLifeCycle.java:87)
at org.glassfish.tyrus.tests.qa.lifecycle.ProgrammaticEndpoint.onClose(ProgrammaticEndpoint.java:100)
at org.glassfish.tyrus.core.EndpointWrapper.onClose(EndpointWrapper.java:498)
at org.glassfish.tyrus.server.TyrusEndpoint.onClose(TyrusEndpoint.java:181)
at org.glassfish.tyrus.websockets.DefaultWebSocket.onClose(DefaultWebSocket.java:95)
at org.glassfish.tyrus.websockets.frametypes.ClosingFrameType.respond(ClosingFrameType.java:57)
at org.glassfish.tyrus.websockets.DataFrame.respond(DataFrame.java:102)
...snip...





[TYRUS-182] Separate servlet 3.0 and 3.1 dependencies into two different modules Created: 19/May/13  Updated: 19/May/13

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.x-backlog

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


 Description   

Separate servlet 3.0 and 3.1 dependencies into two different modules. That helps uptake of tyrus into appservers that don't have 3.1 support.






[TYRUS-185] Composition of different frame/message processors Created: 19/May/13  Updated: 19/May/13

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.x-backlog

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


 Description   

We need composition of frame/message processors in Tyrus. That way, one can set up a pipeline based on the requirements. For simple endpoints, one could gather different frame/message processor requirements from endpoint method types and HTTP headers in the handshake. I could think of different pipelines for execution,

for e.g: A pipeline could be constructed using combination of the following processors for input messages.

Frame parser – (per-message | per-frame) extesion * - subprotocol handler * - Decoder Processor - Invoker

We can set up optimized pipeline based on the requirements and per connection.






[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-204] Improve client-side proxy support Created: 24/Jun/13  Updated: 04/Apr/14

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

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


 Description   
  • proxy authentication
  • ProxySelector support

please vote/comment if you want this to be implemented.



 Comments   
Comment by jewel-sea [ 26/Aug/13 ]

We have an upcoming project where we would like to install a Tyrus based Websocket client behind enterprise firewalls which can only communicate to a cloud hosted service via port 443 outbound. In such a deployment, it is possible that some of our customers may use an authenticated proxy on port 443 outbound. We would like to see client-side proxy support in Tyrus improved to handle this functionality so that we can offer this deployment option to our customers.

Our deployment architecture is similar to http://cloudbees.foxweave.com/images/blog/websockets-and-transparent-proxies/images/in-house-deployment-illustration.png (note that is not our project, but the FoxWeave agent running as a websocket client operating within the enterprise firewall operates in a somewhat similar manner).

Comment by Pavel Bucek [ 27/Aug/13 ]

Thanks for your comment!

Can you please list auth schemes which you consider as must-have?

Comment by jewel-sea [ 19/Dec/13 ]

I am more familiar with http style proxy auth than websocket style proxy auth (maybe they actually end up being the same thing). But I think the required auth mechanism would be basic auth and (potentially) digest auth.

Comment by kimiy [ 10/Mar/14 ]

We have same problem. We try to connect through client-side proxy, but proxy returns "HTTP/1.1 407 Proxy Authentication Required".

Comment by Pavel Bucek [ 10/Mar/14 ]

@kimiy: can you please add information about authentication scheme(s) your proxy supports/requires? Thanks!

Comment by kimiy [ 11/Mar/14 ]

Our proxy requires Basic authentication scheme.

Comment by Pavel Bucek [ 11/Mar/14 ]

@kimiy, can you please try following branch - just to see whether it will work for you?

https://github.com/pavelbucek/tyrus/tree/proxy-headers

(clone, build using "mvn clean install -Dmaven.test.skip" and then use Tyrus libraries version 1.6-SNAPSHOT)

It adds support for changing headers of request to be used as proxy "handshake". Simple usage is present in EchoTest:

            client.getProperties().put(GrizzlyClientSocket.PROXY_URI, "http://my.proxy:8080"); // or -Dhttp.proxyHost and -

final HashMap<String, String> headers = new HashMap<String, String>();
headers.put("Proxy-Authorization", "Basic " + Base64Utils.encodeToString("username:password".getBytes(Charset.forName("UTF-8")), false));

client.getProperties().put(GrizzlyClientSocket.PROXY_HEADERS, headers);

Please try to replace "username:password" with your credentials. (I don't have any proxy which requires authentication currently available).

Also any comments about this (low-level) solution is also welcomed. I think we can come up with better, high level solution, something similar to jersey or apache http client, but that will require more time (and we will most likely start with standard authentication rather than jump into proxies).

Thanks and regards,
Pavel

Comment by kimiy [ 12/Mar/14 ]

I tried it, and I got success to connect through client-side proxy with authentication.
In our case, its solution works well.

Thank you so much.

Comment by Pavel Bucek [ 12/Mar/14 ]

great, thanks for confirmation. I'll clean up the code and merge this workaround to master branch.

Comment by mthornton [ 04/Apr/14 ]

The proxies we see are mostly Windows IIS with domain authentication. Our users want the authentication to proceed using cached credentials (i.e. the one used to login to Windows). The authentication schemes accepted are typically Negotiate, Kerberos and NTLM. Basic is NOT permitted.

The standard Java HttpURLConnection does manage to negotiate these proxies.





[TYRUS-220] Implement batching support in RemoteEndpointWrapper Created: 25/Jul/13  Updated: 04/Nov/13

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

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





[TYRUS-231] BeanValidation integration Created: 09/Aug/13  Updated: 09/Aug/13

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

Type: New Feature 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   
  • BV integration (without EJB, CDI or other container)
  • improved error reporting (instanceof check in @OnError is not nice pattern)





[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-267] Implement WebSocket subprotocol support Created: 01/Nov/13  Updated: 01/Nov/13

Status: Open
Project: tyrus
Component/s: core
Affects Version/s: 1.3
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


 Description   
  • xmpp, stomp, json, xml, ...
  • (might be implemented as more robust version of encoders/decoders)





[TYRUS-278] Tyrus should be able to broadcast over a farm using JMS of other similar technology Created: 04/Dec/13  Updated: 04/Dec/13

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

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


 Description   

It would make a look simpler if Tyrus contains features natively to support using JMS queue or similar technology such as coherence to support sending messages to multiple nodes in the farm:

@ServiceEndpoint(...)
@TyrusCluster()
@TyrusJMSQueue(... something to configure a suitable queue ... )
public class MyClusteringEndpoint
{
}

This would probably only come into play if you make use of the new broadcast method on TyrusSession:

((TyrusSession)peer).broadcast(message)

The implication here is that is we were to allow filtering on the broadcast...

((TyrusSession)peer).broadcast(message, Session::isOpen)

.... this would probably require an interface that could be serialisable:

public interface SerializablePredicate<T>
extends Predicate<T>, Serializable {
}

You would have to be careful to not allow anonymous inner classes in this case as it would end up trying to serialise the entire outer object. I am not sure Lambda would be dealt with this incase, I guess you would have to make sure it doesn't capture too much of the containing state. I would get the ObjectOutput stream would fail in these cases.






[TYRUS-279] TyrusSession.broadcast should allow the client to provide a predicate Created: 06/Dec/13  Updated: 06/Dec/13

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

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


 Description   

I feel that TyrusSession.broadcast should take a Predicate filter so that messages can easily be sent to sub sections of the connected clients.

So it should be possible to do something like this:

((TyrusSession)session).broadcast(message, s -> s.getUserProperties().conains("NAME"));

Ideally the interface should be serialisable so that the same expression could be used across the cluster as per bug TYRUS-278, you do need to be a little bit careful in this case as this blog shows:

http://kingsfleet.blogspot.co.uk/2013/12/lambda-will-it-serialize.html

Obviously the code will be written in a form that will work with JDK6 but can be more pleasant to use with JDK 8.






[TYRUS-300] Introduce better support for QueryParams Created: 06/Mar/14  Updated: 27/Mar/14

Status: Open
Project: tyrus
Component/s: samples
Affects Version/s: None
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


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

(see JAX-RS @QueryParam)





[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-315] Creating javadoc with JDK8 fails, because of <p/> tags in javadoc. Created: 08/Apr/14  Updated: 25/Jan/16

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

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





[TYRUS-316] Introduce configurable write timeout (basic remote) Created: 10/Apr/14  Updated: 26/Jun/14

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: 1.5
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


 Description   

sometimes it might happen (infra issues) that synchronous call is never completed.

Then Tyrus should have some timeout to be able to unblock itself/client/application.






[TYRUS-331] Support for running websocket client inside sandbox Java applet Created: 16/Jun/14  Updated: 16/Jun/14

Status: Open
Project: tyrus
Component/s: client, core
Affects Version/s: 1.6
Fix Version/s: None

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

WildFly 8.1.0 application server, sandbox Java applet that uses Tyrus websocket client.



 Description   

Tyrus websocket client doesn't function out of the box within sandbox applet due to its restrictions and security limitations. There were 2 major problems with the existing code base: access to system properties (restricted in
sandbox except for few specific Java properties, see http://docs.oracle.com/javase/tutorial/deployment/doingMoreWithRIA/properties.html) and some Java reflections code that behaves differently in Sandbox applet than in a standalone application.

Below is the list of changes we've implemented to resolve the issue in Tyrus project (Grizzly project has a much bigger list):

1. /containers/grizzly-client/src/main/java/org/glassfish/tyrus/container/grizzly/client/GrizzlyClientSocket.java
Made conditional access to system properties (when having no access - in sandbox applet, use predefined default).
Also made conditional access to proxy settings (not allowed in sandbox).

2. /core/src/main/java/org/glassfish/tyrus/core/ReflectionHelper.java
getParameterizedClassArguments method behaves differently in sandbox and in standalone application. Specifically,
p.genericInterface is never instance of ParameterizedType (Java reflection getGeneric... methods do not return the correct type in sandbox
for typed classes; for example, in standalone application we get MyClass.InnerClass<T> while in sandbox we get only MyClass.InnerClass
only). As a workaround resolution, we hard coded specific org.glassfish.tyrus.core.coder.X classes instead of dynamic resolution.

Probably the solution we've implemented is not the best so it is just a hint on what should be fixed and where.






[TYRUS-349] Using system/browser (SSL) keystore when running in applet code Created: 29/Jul/14  Updated: 29/Jul/14

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

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

Tags: applet, cacerts, ssl

 Description   

When using an SSL secured connection to a WebSocket server in a Java-Applet only the certificates in the keystore of the JRE (cacerts file) were checked.

If using a HttpsURLConnection in a Java-Applet it automatically uses the system keystore (Internet Explorer on Windows) or the browser keystore (Firefox).

The websocket client should behave like the HttpsURLConnection.






[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-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-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-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-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-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-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-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-408] Gradually Increasing Memory Usage with Tyrus Standalone Client 1.11 Created: 31/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: Major
Reporter: spstur Assignee: Pavel Bucek
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.





[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-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-416] Hostname variable is not used Created: 27/Nov/15  Updated: 27/Nov/15

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

Type: Improvement Priority: Major
Reporter: Christian_Schmidt Assignee: Unassigned
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-75] Implement client to use the scanned classes when started in EE container. Created: 28/Jan/13  Updated: 08/Mar/13

Status: Open
Project: tyrus
Component/s: None
Affects Version/s: None
Fix Version/s: 1.x-backlog

Type: New Feature Priority: Minor
Reporter: stepan.kopriva 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-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-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-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-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-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-323] Reuse TaskProcessor from Grizzly containers in JDK container Created: 19/May/14  Updated: 19/May/14

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

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


 Description   

TaskProcesssor used in both Grizzly server and client container uses the same logic as TaskQueueFilter in JDK client






Generated at Tue Feb 09 22:00:53 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.