cometd / cometd Goto Github PK

The archetypes' web.xml and demo's web.xml should be updated by adding the CrossOriginFilter from Jetty7.

[2009-11-02 14:01:24,810 WARN ] [HttpClient-11] [org.eclipse.jetty.util.log.Slf4jLog:91] EXCEPTION on HttpExchange@29759410=POST//preprod.qnh-ajt.eu:80/groundcontrol/cometd/publish4
org.eclipse.jetty.io.EofException
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:310)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:203)
at org.eclipse.jetty.client.HttpConnection.handle(HttpConnection.java:271)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:438)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:435)
at java.lang.Thread.run(Thread.java:619)
[2009-11-02 14:01:24,841 WARN ] [HttpClient-11] [org.eclipse.jetty.util.log.Slf4jLog:78] org.cometd.client.BayeuxClient@ba5c7a: org.eclipse.jetty.io.EofException
[2009-11-02 14:01:24,841 WARN ] [HttpClient-11] [org.eclipse.jetty.util.log.Slf4jLog:78] IOE on HttpExchange@29759410=POST//preprod.qnh-ajt.eu:80/groundcontrol/cometd/publish9

It would be useful to have a synchronous disconnect() to be invoked from onunload browser handlers.
Having it synchronous will make the browser wait until the response arrives and will avoid (hopefully) that the browser kills the javascript runtime before the disconnect hits the network.
For the implementation, it can rely on XHR.open(method, url, async).

The reload extension functionality is broken in several ways.

The server is not able to handle an outstanding connect followed by another connect; this is a side effect of the changes that were introduced by fixing #40 in ContinuationClient.

The JavaScript client starts an internal batch during the handshake request; this internal batch is ended on the first successful connect response. However, even though the reload extension does replay the handshake response, it does not have the typical "connect-request + connect-response + connect-request" cycle of a normal handshake; it only has "connect-request". Therefore the internal batch is not ended until the connect returns, which only happens after the long poll timeout. This causes the application to seem hung until the connect returns.

BayeuxService.doInvoke() incorrectly identifies the parameter type for subscription callbacks with the following signature by testing the type of the second parameter instead of the third to see if it implements Message.

method(Client, String, Message, String).

I've attached a diff to solve the issue.

Extension.sendMeta() is invoked twice when a disconnect message arrives to the server.

This tracks JETTY-1161.

Javascript Date.toUTCString() returns a string version of the Date using the English language. If the JVM is running with a different Locale, SimpleDateFormat.parse() will fail.
Attached patch

The AcknowledgeExtension does not test to see if the channel in the Message it has been passed in sendMeta() method is null.

When using Spring along with other frameworks (such as, for example, Struts2), the strategy of overriding Spring's default loading mechanism may not work, because the framework may need to initialize Spring before the CometD servlet.

For example, Struts2 is configured via a servlet filter which cannot be configured using <load-on-startup> to be initialized after the CometD servlet. When Struts2 is integrated with Spring, initialization of the Struts2 filter triggers Spring initialization.

Document the pattern of using lazy initialization for Bayeux services.

It would be good to write a binding for the java client API that worked with GWT

In case the server disconnects, the long poll is returned with an advice to re-handshake.
Re-handshaking implies that the clientId is nulled out, so any publish() between the re-handshake request and a successful re-handshake response will be sent without clientId.

When using long polling transport, and the network cable is unplugged, the client cannot detect that the communication with the server has been interrupted.
This leaves the client in an inconsistent state, while the server normally times out the client.
On later re-plug of the cable, the client is not able to reconnect properly to the server.

The method Bayeux.removeExtension(Extension extension) is missing.
It should be added, I guess.

See http://jira.codehaus.org/browse/JETTY-1134.

It would be good to have a customizable function called every time a listener/subscriber throws an error.

For our open source product we depend on getting information on connection problems, so we can reinit the connection. We tried to add a RemoveListener, but this listner is never called (when you look at the BayeuxClient.java), it is only added to the list of removeListeners.

It would be good to have a customizable function called every time an extension throws an error.

[Ticket raised following thread at http://groups.google.com/group/cometd-dev/browse_thread/thread/3afa4e0a3d632d10]

The long-polling response includes a "timeout" advice field, indicating the maximum time before a long-poll completes. This field should be documented in the spec. (e.g. section 6.1.2, "long-polling response messages").

haven't enough commas
'000' instead of just '0' (simplejson throw exception for more then one '0')
"true" and "false" instead of true/false without quotes

Any extra object passed to handshake() is saved so that it can be used in case of automatic reconnects.
However, a deep copy of the object is made, so that modifications to the extra handshake object are not used in a subsequent reconnect.
Given that using extensions it is always possible to customize the handshake message (or even replace it completely with another), having the extra handshake object immutable is just a complication for users.

This bug is due to changes in Jetty 7.0.1 where calling resume() on an expired continuation throws IllegalStateException as per the Servlet 3.0 specification.

when i send request:
[{"channel":"/meta/subscribe","subscription":"/chat/demo","id":3,"clientId":"fuUU0LSBqoDCMI7Wzx9PozKseAdZoX8uFPkB2QF"},{"channel":"/meta/subscribe","subscription":"/chat/members","id":4,"clientId":"fuUU0LSBqoDCMI7Wzx9PozKseAdZoX8uFPkB2QF"},{"channel":"/service/members","data":{"user":"mico","room":"/chat/demo"},"id":5,"clientId":"fuUU0LSBqoDCMI7Wzx9PozKseAdZoX8uFPkB2QF"},{"channel":"/chat/demo","data":{"user":"mico","membership":"join","chat":"mico has joined"},"id":6,"clientId":"fuUU0LSBqoDCMI7Wzx9PozKseAdZoX8uFPkB2QF"}]

i have received:
[{"successful": true, "clientId": "fuUU0LSBqoDCMI7Wzx9PozKseAdZoX8uFPkB2QF", "channel": "/meta/subscribe"}, {"successful": true, "clientId": "fuUU0LSBqoDCMI7Wzx9PozKseAdZoX8uFPkB2QF", "channel": "/meta/subscribe"}, {"successful": true, "id": 5, "channel": "/service/members"}, {"successful": true, "id": 6, "channel": "/chat/demo"}]

there is no 'id' and 'subscription' fields at first and second answers.

The documentation does not explain how the JavaScript client code should be used if the user does not want to use Dojo or jQuery.

It should explain the necessary steps, or at the very least point out that jQuery and Dojo adapters can be perused for help.

It is very easy to make the server fail when, from the JS client, calls to the public methods are made without the required parameters.

cometd.publish(); // Missing channel and data

results in:

java.lang.NullPointerException
    at org.cometd.server.AbstractBayeux.handle(AbstractBayeux.java:282)

and

cometd.publish({}); // Missing channel

results in:

java.lang.Error
    at org.cometd.server.AbstractCometdServlet.getMessages(AbstractCometdServlet.java:322)
    ...
    at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassCastException: java.util.HashMap cannot be cast to java.lang.String
    at org.cometd.server.MessageImpl.put(MessageImpl.java:258)

And a moment later the connect fails with a JSON parsing error (this may be another bug in the server side):

java.lang.Error
    at org.cometd.server.AbstractCometdServlet.getMessages(AbstractCometdServlet.java:322)
    ....
    at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: unknown char ','(44) in org.eclipse.jetty.util.ajax.JSON$ReaderSource@3085a863
    at org.eclipse.jetty.util.ajax.JSON.handleUnknown(JSON.java:807)

Checks should be performed in the client to avoid these problems, as people monitor their server and can worry seeing these errors.

This tracks jetty issue http://jira.codehaus.org/browse/JETTY-1162.

In jetty-6, message notification to message listeners inside the deliver(Client from, Message message) always happens inside the sync block on the _inQ. This was changed to be more like the server-side clients, with the use of Async and Sync MessageListeners.

The org.cometd version of BayeuxClient always delivers all messages outside of the sync block, however it may be a good idea to introduce the Sync MessageListener to allow for sync delivery.

If an Extension returns null from rcv, a NlulPointerException is thrown from PublishHandler.handle method at this line:
String channel_id=message.getChannel();

Needs protection of if (message == null) return;

Jan

http://www.ietf.org/rfc/rfc4627.txt states that the mime type for JSON should be "application/json", but the jetty cometd impl uses "text/json".

The Bayeux Protocol specification mentions "timeout" multiple times, but it does not explain how it should be implemented anywhere

Running the cometd-demo via the Jetty Maven plugin, then touching the web.xml file to cause a hot redeploy, causes the long poll to stop.
Seems like the webapp redeploys, but the long poll is not resumed until it times out, and then it returns with an empty body that causes the client to abort (as it does not understand an empty JSON response).

See http://jira.codehaus.org/browse/JETTY-1183.

The specification for deliver event messages suggests that the message may include the publishers clientId.

This should be clarified so that it is made explicit that the clientId is only included in deliver event messages sent to the original publisher of that message - not to subscribers in general.

Update jQuery to 1.4.2

A full chat example using Java's BayeuxClient would be helpful to better understand how to best use Java's Bayeux client API.

http://svn.cometd.com/trunk/bayeux/bayeux.html#toc_37
This references Section 4.7 for more details on connection types. The section 4.7 is not there and I could not find the explanation of the connection types in the document.

Document how to perform authentication

See http://jira.codehaus.org/browse/JETTY-875.

When the Bayeux policy denies the handshake, it normally would want to customize the response's advice to set (at least) reconnect: "none", but possibly also the reason for the deny so that the client can inform the user.

In CometD 1 doing this was possible using an extension, but it was a bit cumbersome and required intimate knowledge of the times at which the policy and extensions were called.
The goal is to make is simpler for CometD 2.

The java-client appends the type of the cometd message to the url, eg handshake, publish, connect. This allows the server-side to apply standard servlet filters with url pattern matching and it would be good to be able to do this with the javascript client as well.

See http://jira.codehaus.org/browse/JETTY-1182.

The jquery-json plugin used by Cometd's javascript-jquery component was updated in August with a version which supports browsers with built-in JSON support. Native browser JSON methods are significantly faster than ones written in Javascript.

See http://jira.codehaus.org/browse/JETTY-1170.

The "evalJSON" method from the jquery-json library performs an unchecked "eval" on the supplied string, potentially opening up a variety of security concerns. The same library also offers a "secureEvalJSON" method which uses regexes to ensure that the code cannot be malicious (contain function calls, etc.) before executing it. Attached is a patch against /trunk/cometd-javascript@787

And document the mechanism!

It may happen that the offset is absent or NaN, and in both cases would return null in TimesyncExtension, line 154.

java.lang.NullPointerException
at org.mortbay.cometd.continuation.ContinuationClient.lazyResume(ContinuationClient.java:132)
at org.mortbay.cometd.ClientImpl.doDelivery(ClientImpl.java:188)
at org.mortbay.cometd.ClientImpl.deliverLazy(ClientImpl.java:130)
at com.chess.live.AbstractService.send(AbstractService.java:367)
at com.chess.live.AbstractService.send(AbstractService.java:301)
at com.chess.live.demo.DemoUserService.sendStatus(DemoUserService.java:238)
at com.chess.live.demo.DemoUserService.addUserToLists(DemoUserService.java:185)
at com.chess.live.demo.DemoUserService.login(DemoUserService.java:367)
at com.chess.live.ClientManager.login(ClientManager.java:361)
at com.chess.live.ChessClientBayeuxListener.clientAdded(ChessClientBayeuxListener.java:51)
at org.mortbay.cometd.AbstractBayeux.addClient(AbstractBayeux.java:512)
at org.mortbay.cometd.ClientImpl.(ClientImpl.java:74)
at org.mortbay.cometd.continuation.ContinuationClient.(ContinuationClient.java:43)
at org.mortbay.cometd.continuation.ContinuationBayeux.newRemoteClient(ContinuationBayeux.java:51)
at org.mortbay.cometd.AbstractBayeux$HandshakeHandler.handle(AbstractBayeux.java:1188)
at org.mortbay.cometd.AbstractBayeux.handle(AbstractBayeux.java:279)
at org.mortbay.cometd.continuation.ContinuationCometdServlet.service(ContinuationCometdServlet.java:108)
at org.mortbay.cometd.AbstractCometdServlet.service(AbstractCometdServlet.java:250)

The problem is that the constructor of ContinuationClient calls its super constructor, which is ClientImpl, which in turn calls the AbstractBayeux class, which invokes the clientAdded listeners - and if one of these listeners attempts to send a (in this case lazy) message, the _bayeux instance in the ContinuationClient is not yet set as we are still inside it's super constructor.

Extension.send() is wrongly called when a plain message is published and arrives to the server.

cometd-twisted does close connection for every request, no long-polling connection.

in ConnectedState.deliver:

            '''
            Only close the stream here if we've used it here.
            Otherwise leave it open. The HTTP buildResponse will make use of it.
            '''
            if self.ctypeProps["closeOnDelivery"]:
                GlobalLogger.info("Close stream on delivery")
                self.stream.finish()

comet_js_headers.py:

    "callback-polling": {
        # NOTE: the "callback-polling" method can be used via ScriptSrcIO for
        # x-domain polling
        "closeOnDelivery": True,
        "preamble":     "",
        # "envelope":       "cometd.deliver(%s);",
        "envelope":     "(%s)",
        "keepalive":    " ",
        "signoff":      "",
        "tunnelInit":   "",
        "contentType": "text/javascript"
    },

The BayeuxClient doesn't try to reconnect when it gets a 503 from the apache server (Service Temporarily Unavailable)

Instead it seems to get in a kind of strange state. Even after the jetty server comes up again, the reconnect isn't performed.
I guess this is caused because the http connection returns an HTML page.

After the fix for #32, the server is not able to derive the correct charset encoding from the mime type (for mime type "application/json" the charset should be UTF-8) and uses ISO-8859-1 as default.
This results in garbled text contained in Bayeux messages sent to clients.

For the first handshake, if the AckExtension supported by server side, property "_serverSupportsAcks" will be set with true, when it works with ReloadExtension and after page refreshing, the value of _serverSupportsAcks has been set with "false" and "missed" the already received message.