atmosphere / atmosphere-javascript Goto Github PK

If custom headers are defined they aren't attached when the Atmosphere protocol close message is sent.

Mirror of Atmosphere/atmosphere#1315

Mirror of Atmosphere/atmosphere#1102

Stomp is a standard subprotocol for Websocket documented here http://jmesnil.net/stomp-websocket/doc/.
Spring 4 has started using it for its web messaging feature. They combine it with sockjs to get automatic fallback options. I think Atmosphere is also a good candidate too.

Today I updated a perfectly running Atmosphere GWT20 1.1.0 RC4 (Atmosphere 2.0 RC2) application with the latest version of atmosphere.js.

My app is not working anymore. I do not receive any messages on the client side.
I checked the differences in the versions and the only differences is what I printed in the screenshot.

What is wrong here?

see

When using websocket I get the following console errors:

Uncaught TypeError: Cannot call method 'toString' of undefined atmosphere.js:2572
atmosphere.util.trim atmosphere.js:2572
_handleProtocol atmosphere.js:1254
_trackMessageSize atmosphere.js:1297
_executeWebSocket._websocket.onmessage

Setting the flag executeCallbackBeforeReconnect to false doesn't make onReconnect handler called after successful re-connection.

Tested with chrome.

#24
Atmosphere/atmosphere#1102

see

Hello,

I'm using atmosphere.js v 2.1.1 and I observe strange behavior while reconnecting with streaming transport. On exceeding streaming length several reconnection requests are made.

Enable protocol and track message size are turned on.
Reproduced in chrome 32

_executeRequest 
_reconnect 
reconnectF 
ajaxRequest.onreadystatechange 
_clearState 
_verifyStreamingLength 
ajaxRequest.onreadystatechange

— clear state resets xhr request which fires onreadystatechange which fires _reconnect as readystate == 4

_executeRequest 
_reconnect 
_verifyStreamingLength 
ajaxRequest.onreadystatechange

— explicitly make reconnection.

Later on one connection gets data, another hangs around.
On the next streaming length exceeding reconnection process loops
And then exception appears

Uncaught Error: message length "lue":4.0}]}65" is not a number
_trackMessageSize 
ajaxRequest.onreadystatechange

How can I disable the console output for atmosphere.js?

Add a method isSubscribed() or isConnected() to Atmosphere's socket object, so that one can check whether the client is already connected to the server or not (i.e. before pushing data).

So that we can do:

if (socket.isSubscribed()) {
socket.push(data);
}

Plus add documentation for the new method in wiki:

https://github.com/Atmosphere/atmosphere/wiki/jQuery.atmosphere.js-API

When triggering disconnection in js client 2.0.6, browser freezes on an opened connection;
I compared requests sent for disconnection on both versions, and there is a difference:

Runtime 2.0.1 / JS Client 2.0.3:

GET /application/event/?X-Atmosphere-Transport=close&X-Atmosphere-tracking-id=0330bc0a-ac59-46fd-951c-bb818880aff8&_=1383047834335 HTTP/1.1
Accept: */*
Accept-Language: fr-BE
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Accept-Encoding: gzip, deflate
Host: 127.0.0.1:8888
DNT: 1
Connection: Keep-Alive
Cookie: JSESSIONID=16yets032qb8e
Referer: http://127.0.0.1:8888/Application.jsp?gwt.codesvr=127.0.0.1:9998#FCA_CUSLIST.DEFAULT
Content-Type: text/x-gwt-rpc; charset=UTF-8

AtmosphereResource{
     uuid=4dff4375-14d0-4e45-a9d1-0f8111fede61,
     transport=UNDEFINED,
     isInScope=true,
     isResumed=false,
     isCancelled=false,
     isSuspended=false,
     broadcaster=/application/event size: 1,
     atmosphereHandler=com.fircosoft.cdb.server.event.EventMessageHandler@2b5bde56,
     action=Action{timeout=-1, type=CREATED}}

Runtime 2.0.3 / JS Client 2.0.6:

GET /application/event/?X-Atmosphere-Transport=close&X-Atmosphere-tracking-id=07782c9d-d042-44a1-8307-9fac51d3f2fb&_=1383048787241 HTTP/1.1
Accept: */*
Referer: http://127.0.0.1:8888/Application.jsp?gwt.codesvr=127.0.0.1:9998#FCA_CUSLIST.DEFAULT
Accept-Language: fr-BE
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Accept-Encoding: gzip, deflate
Host: 127.0.0.1:8888
DNT: 1
Connection: Keep-Alive
Cookie: JSESSIONID=u555j11uefob
Content-Type: text/plain
X-Atmosphere-Framework: undefined
X-Atmosphere-Transport: polling
X-Cache-Date: 0
X-Atmosphere-tracking-id: undefined

AtmosphereResource{
     uuid=undefined,
     transport=POLLING,
     isInScope=true,
     isResumed=false,
     isCancelled=false,
     isSuspended=false,
     broadcaster=/application/event size: 1,
     atmosphereHandler=com.fircosoft.cdb.server.event.EventMessageHandler@420b2dc4,
     action=Action{timeout=-1, type=CREATED}}

This results in a polling connection opened instead of closing the current one.
Debugging on server side, for instance in OnDisconnectInterceptor, 'polling' transport isn't handled as a disconnection at all (used to be 'close' transport).

Commit 1726b98 incorrectly adds removal of all heading and trailing white space in addition to removal of all newline characters (if I read the code correctly). Any message ending or starting with whitespace will therefore be incorrectly handled, e.g. an empty whitespace "1| " will be trimmed into "1|" and after that processing is messed up.

WebKit invokes the XHR.onerror callback when a send fails due to the server or the network being down. This is fine, unlike Firefox which pretends the connection succeeds and is immediately closed.

However, the ajaxRequest.onerror callback in _executeRequest always calls _clearState independent of the value of _response.errorHandled. This has the effect that clearTimeout(_request.id) is called, clearing the scheduled reconnection attempt. And since _response.errorHandler is true, no new reconnection is scheduled.

This is a regression in the 2.0 series, as the 1.0.x _clearState did not call clearTimeout. Moving the _clearState call inside if(!_response.errorHandler) fixes this bug but I'm not sure whether it causes regressions elsewhere.

Happens in two different situations:

1. When JSONP is used
2. When CORS is used with long-polling and the OPTIONS request is sent

Tested version: Atmosphere 1.0.13

I'm using Atmosphere 1.0.13 and changed the timeout value to

myVar.cfg.request.timeout = 10000; // low value of 10 seconds to make testing easier.

If I now close the connection by using

auctionPushSocketVar.connection.close();

I can see in the browser that the connection is closed correctly. However after 10 seconds the server got an incoming request and this keeps happening until the browser is closed.

The problem is that the connection has been started by setTimeout but is never cleared on close.

I verified the source code and changed the close method:

function _close() {
    _request.reconnect = false;
    _abordingConnection = true;
    _response.request = _request;
    _response.state = 'unsubscribe';
    _response.responseBody = "";
    _response.messages = [];
    _response.status = 408;
    _invokeCallback();

    _clearState();

    // BEGIN ADDED CODE
    if (_request.id) {                   
        clearTimeout(_request.id);
    }
    // END ADDED CODE
}

This solves the problem.

Unfortunatly I'm not able to test with 2.0.0 RC since I'm using Primefaces but this seems like a good bug-fix for the 2.0.0 release.

Mirror of Atmosphere/atmosphere#1313

In atmosphere.js _websocket.onopen, the _open() function (and thus any onOpen and onReopen callbacks supplied by the user) is called before the _websocket.webSocketOpened flag is set to true. This means that if the user tries to push from onOpen or onReopen, it will fail in _pushWebSocket line 11785.

Do you see any issues in changing the order of setting the flag and calling _open? If not, I can submit a patch.

Version: master

Hi,
Currently it's possible to do: socket.subscribe(request, myCallback);
And myCallback will be called once the connection is established.

The problem is that the callback is put in the global callbacks array. Thus it will also be run many other times:

If you do a refresh, it is run 5 times:
Invoking 1 global callbacks: closed
Invoking 1 global callbacks: closed
Invoking 1 global callbacks: unsubscribe
Invoking 1 global callbacks: closed
Invoking 1 global callbacks: opening

If the request timeout it will run 2 times:
Invoking 1 global callbacks: closedByClient
Invoking 1 global callbacks: closed

If I simply close the page, it will run 1 time:
Invoking 1 global callbacks: unsubscribe

Using atmosphere-runtime-native 2.0RC5 and atmosphere.js 2.0.3-javascript using Tomcat 7.0.43dev.

My browser shows the following error and the connection fails. Note that the same code is working with Tomcat 7.0.42.

WebSocket connection to 'ws://www.buddy.is/socket/notification/848df2e62fcf93e1b3?X-Atmosphere-tracking-i…Date=0&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true' failed: Unrecognized frame opcode: 5 atmosphere.js:962
Websocket reconnect maximum try reached 0 atmosphere.js:2793

In https://github.com/Atmosphere/atmosphere-javascript/blob/master/modules/jquery/src/main/webapp/jquery/jquery.atmosphere.js#L2171
It would be possible to check if message is an ArrayBuffer or Blob and leave it as it then (they match 'object' type thus failing if dev wants to use socket.send(arraybuffer), generally used for multimedia push like videoconferencing+websocket).

This is because the _request.closed flag is set in _f() case "closed" but never cleared.

I use atmosphere.js But lately I was wondering how and if two Atmosphere.js modules (module A and module B) can share an Atmosphere resource.

using atmosphere-runtime-native 2.0.3 und atmosphere.js 2.0.6

I get the following debug messages:

M1: atmosphere module 1,
M2 atmosphere module 2

When I load the page the first time (I cleared the browser cache before) then I found that the following events occur:

On client side:

Invoking executeSSE
Using URL: http://myurl:8080/test/socket/notification/848df2e62fcf9…osphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json; charset=UTF-8&X-atmo-protocol=true 
M1: atmosphere created
SSE successfully opened 
M1: connection open
M1: send Message
M1: onMessage
Invoking executeSSE 
Using URL: http://myurl:8080/test/socket/chat/848df2e62fcf93e1b3?X-…osphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json; charset=UTF-8&X-atmo-protocol=true 
M2: atmosphere created
SSE successfully opened

On server side:

M1: onPreSuspend
M1: onSuspend
M1: onBroadCast
M2: onPreSuspend
M2: onSuspend

Somehow after reconnect or when the client pc comes from sleep, the recieved data gets stuck in a loop and atmosphere thinks it's comes from the server. so if for example the server sends "1","2","3" when the issue happens it just starts to receive "1","2","3" "1","2","3" "1","2","3" and so on which causes the browser to leak memory and use a lot of cpu until it crashes.

I'm pretty sure it's an issue in the client and not server (I don't use cache for the specific channel)

I'm using atmopshere 1.0.13, windows server 2008, tomcat 7.0.43, jdk jdk1.6.0_45 64bit, using streaming

I'm not able to reproduce it locally.

Mirror of Atmosphere/atmosphere#1126

Atmosphere: v2.0.0.RC1
jquery.atmosphere.js: v2.0.0-jquery
TrackMessageSizeFilter enabled: true
useNative: true
useWebSocket: true
asyncSupported: true

This setup works fine on Chrome, Mozilla FF and IE9 but on IE8 only the first message (sometimes a few) is received and later the server stops sending messages to this resource.

The issue is on client side (jquery.atmosphere.js) inside _trackMessageSize method browser does not get a valid message to parse. Messages look like this:

Message 1-) 123|{Message_1} // Works fine
Message 2-) {Message_2}\n123|{Message_1} // Throws exception

The first message is OK. _trackMessageSize method removes messageLength and delimiter from the message so we can retrieve original message.
The second message throws exception, because _trackMessageSize method retrieves the messageLength as "{Message_2}\n123" which is not a valid integer.

See the related code chunk below:

            function _trackMessageSize(message, request, response) {
                if (!_handleProtocol(_request, message)) return true;
                if (message.length == 0) return true;

                if (request.trackMessageLength) {
                    // prepend partialMessage if any
                    message = response.partialMessage + message;

                    var messages = [];
                    var messageStart = message.indexOf(request.messageDelimiter);
                    while (messageStart != -1) {
                        var str = jQuery.trim(message.substring(0, messageStart));
                        var messageLength = parseInt(str, 10);
                        if (isNaN(messageLength))
                            throw 'message length "'+str+'" is not a number';
                        messageStart += request.messageDelimiter.length;
                        if (messageStart + messageLength > message.length) {
                            // message not complete, so there is no trailing messageDelimiter
                            messageStart = -1;
                        } else {
                            // message complete, so add it
                            messages.push(message.substring(messageStart, messageStart + messageLength));
                            // remove consumed characters
                            message = message.substring(messageStart + messageLength, message.length);
                            messageStart = message.indexOf(request.messageDelimiter);
                        }
                    }
                    ...
                    ...
                    ...
            }

After the exception is thrown, any further messages will not be retrieved on client side and corresponding resource cannot even be retrieved by broadcaster..getAtmosphereResources(). But other browsers (IE9, Chrome, Firefox) gets messages without any problem. So, is this a bug or i am doing something wrong?

Thanks,

Okan

so a client can re-act when the client timeout value expires.

Simone has a really nice idea here

Mirror of Atmosphere/atmosphere#1128

This should be tested with the portal first to see if it works.

https://groups.google.com/forum/#!topic/atmosphere-framework/9pI2WI-53Jc

http://stackoverflow.com/questions/18774269/websocket-failed-downgrading-to-comet-and-resending

The reconnect mechanism for long-polling is broken when the reconnect timeout value is set

Android 4.1 has a broken websocket implementation which does not even try to contact the server but does not call onerror/onclose either.

Mirror of Atmosphere/atmosphere#1362

This change cause a regression as two subscribed connection will share the same uuid and that will confuse the server. The behavior must ne set to false by default.

When trying to require the library (v2.0.5) node throws "ReferenceError: window is not defined" at line 2712.

I tried going back to 2.0.3, which contained the announcement of node.js compatibility, but it still has the same problem, at line 2688.

A workaround or a fix would be highly appreciated.
Cheers,
Ruby

When trying to push data from the atmosphere js client library from a web browser that doesn't have CORS support only an HTTP error is thrown.

I can't say if it's an error in the code, or if there's a reason it should be like it is, but changing line 1546 fixes it.

Before:

// CORS fake using JSONP
if ((rq.transport === 'jsonp') || ((rq.enableXDR) && (atmosphere.util.checkCORSSupport()))) {
    _jsonp(rq);
    return;
}

After:

// CORS fake using JSONP
if ((rq.transport === 'jsonp') || ((rq.enableXDR) && (!atmosphere.util.checkCORSSupport()))) {
    _jsonp(rq);
    return;
}