[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-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-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-241] l10n - LogLevel INFO+ should be internacionalized. Created: 22/Aug/13  Updated: 19/Feb/14

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-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-196] Implement correct @PreDestroy calling for user provided ServerEndpointConfig.Configurator Created: 17/Jun/13  Updated: 17/Jun/13

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: None
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-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-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-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-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-374] Websocket engine is invoked on Grizzly even if the application and request context root do not match Created: 09/Sep/14  Updated: 16/Sep/14

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

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





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

Status: Open
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: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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-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-364] @PostConstruct and @PreDestroy of a @ServerEndpoint is not called Created: 22/Aug/14  Updated: 22/Aug/14

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

Type: Bug Priority: Major
Reporter: martinandersson.com Assignee: Unassigned
Resolution: Unresolved 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.





[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-354] Invalid Connection header value: "Keep-Alive" Created: 30/Jul/14  Updated: 30/Jul/14

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

Type: Bug Priority: Major
Reporter: dungld Assignee: Pavel Bucek
Resolution: Unresolved 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!





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

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-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-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-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-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-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-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-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-399] org.glassfish.tyrus.container.jdk.client.ClientFilter processError Connection error has occurred java.io.IOException Created: 24/May/15  Updated: 28/May/15

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

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

Windows XP
Java 1.7.0_55



 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.





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

Status: Open
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: Unresolved Votes: 2
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!





[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-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-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-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-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-392] Unable to use Tyrus 1.9 in android 4.4.2 appllication Created: 02/Jan/15  Updated: 06/Jan/15

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

Type: Bug Priority: Minor
Reporter: hsamu Assignee: Unassigned
Resolution: Unresolved 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-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 Sun Jul 05 00:25:44 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.