nmosafi / aspcomet Goto Github PK

Is this a library bug!!! A lot of request queued on ExecuteRequestHandler state with a high TimeLapse! And this connections never disappears.

nmosafi, can you help me here! 😟

Sometimes javascript client can't make a handshake or connect to the server.
It's an intermittent error.

'Parsererror' exception raises on attempt to parse a json string.

The cause of the problem in the MessageConverter class:

Line 56: stringBuilder.AppendFormat(@"(""{0}"":null)|(,""{0}"":null)", properties[properties.Length - 1].Name);

I think it should be replaced to:

stringBuilder.AppendFormat(@"(""{0}"":null,)|(""{0}"":null)|(,""{0}"":null)", properties[properties.Length - 1].Name);

Otherwise regex doesn't replace commas in some cases.

[Duplicate of Issue 9 from the old code.google.com site - http://code.google.com/p/aspcomet/issues/detail?id=9]

The Dojo JS library uses the "BAYEUX_BROWSER" cookie to enable a server detect multiple CometD clients from the same browser - http://cometd.org/documentation/cometd-java/server/multipleclients

It would be useful for AspComet to detect this cookie and offer a multiple-clients response.

[Duplicate of Issue 15 from the old code.google.com site - http://code.google.com/p/aspcomet/issues/detail?id=15]

The spec @ http://svn.cometd.org/trunk/bayeux/bayeux.html#toc_65 suggests that it's optional for the server to accept a publish without a client id ("It is OPTIONAL for a server to accept unconnected publish requests").

Currently AspComet will publish messages from unconnected clients - and it's possible to prevent that by catching each PublishingEvent and cancelling those without a valid client id.

However, adding a subscription for each PublishingEvent just to check the client id could be a non-trivial overhead. For that reason, the support for unconnected clients should be configurable, e.g. a new property, allowUnconnectedClients, default=true.

If the client is "between" polls, then a message for immediate delivery
will not be delivered to the client until the end of the next long-poll
timeout - a 10 second delay.

If the turn around for the old long-poll response to be returned, cross the
network, be processed by the client, a new long-poll request to be created,
cross the network, and processed by the server is (say) 0.1s, then there is
a gap of 0.1s every 10s where this may happen - or around 1% of the time.

Note; this happens because Client.FlushQueue() will only send the messages
if there is a current long-poll active. If there isn't, the next long-poll
opened by the client isn't flushed immediately.

[Duplicate of Issue 19 from the old code.google.com site - http://code.google.com/p/aspcomet/issues/detail?id=19]

Support for streaming transports has a long discussion at http://code.google.com/p/aspcomet/issues/detail?id=19 that I won't attempt to reproduce here, but I'll raise the issue so that it can be kept track of within this space.

Hello, thanks for your project.

Same Issue as #14 but with another solution for Regex

Env: VS2010, .net4
Browser: FF9.0.1, IE9
Sys: Sys7 x64
Program : Chat-vs2010
Version : downloaded 23/12/2011 23h33

Bug :
Sometimes MessageConverter.ToJson send back a "bad" string with error on format.
Example :

case 1 : FF9.0.1, when click on handshake from cometdTerminal.html
Post on comet.axd/handshake
[{"ext":{"authentication":{"user":"User","credentials":"password"}},"version":"1.0","minimumVersion":"0.9","channel":"/meta/handshake","supportedConnectionTypes":["long-polling"],"id":6}]

Returns :
[{,"version":"1.0","channel":"/meta/handshake","supportedConnectionTypes":["long-polling"],"id":"1","clientId":"Ngv9SfTkgSKQeEaElqZ","advice":{"reconnect":"retry"},"successful":true}]

FF made an error : JSON.parse: expected property name or '}'
return JSON.parse(src); on function $.secureEvalJSON = function(src)
Supposed error : [{, coma should not be there

origin :

MessageConverter.CreateNullRegexString()
You create a long Regex with a lot of possibilities :

("channel":null,)|(,"channel":null)|("clientId":null,)|(,"clientId":null)|("data":null,)|(,"data":null)|("version":null,)|(,"version":null)|("minimumVersion":null,)|(,"minimumVersion":null)|("supportedConnectionTypes":null,)|(,"supportedConnectionTypes":null)|("advice":null,)|(,"advice":null)|("connectionType":null,)|(,"connectionType":null)|("id":null,)|(,"id":null)|("timestamp":null,)|(,"timestamp":null)|("successful":null,)|(,"successful":null)|("subscription":null,)|(,"subscription":null)|("error":null,)|(,"error":null)|("ext":null)|(,"ext":null)

with case 1 message is :
[{"ext":null,"version":"1.0","minimumVersion":null,"channel":"/meta/handshake","supportedConnectionTypes":["long-polling"],"id":"2","clientId":"Xg6gcCTsc7Tgofof60p","data":null,"advice":{"reconnect":"retry"},"connectionType":null,"timestamp":null,"successful":true,"subscription":null,"error":null}]

Converted message :
[{,"version":"1.0","channel":".....

NullRegexString could be
{"[^"*]+":null[,}]?|,"[^"*]+":null

considering : {"blabla":null, {"blabla":null} ,"blabla":null
and message will be fine.

[Duplicate of Issue 8 from the old code.google.com site - http://code.google.com/p/aspcomet/issues/detail?id=8]

Currently, the receipt of a client event terminates any outstanding long-poll, causing it to be immediately re-established.

There's no need for that to happen; the existing long-poll can continue until it times out, or until a server -> client message is required.

Test case

        string txt = "[{\"ext\":null,\"version\":\"1.0\",\"minimumVersion\":null,\"channel\":\"/meta/handshake\",\"supportedConnectionTypes\":[\"long-polling\"],\"id\":\"1\",\"clientId\":\"3YrNzzZoglR07mikmlB6\",\"data\":null,\"advice\":{\"reconnect\":\"retry\"},\"connectionType\":null,\"timestamp\":null,\"successful\":true,\"subscription\":null,\"error\":null}]";
        string result = NullRegex.Replace(txt, string.Empty);

Return:

       [{,"version":"1.0","channel":"/meta/handshake"...}]

You can see the first comma hasn't be removed correctly.

Stack trace:    at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)

at System.Collections.Generic.Queue1.Enumerator.MoveNext() at System.Linq.Enumerable.Any[TSource](IEnumerable1 source)
at AspComet.Client.get_HasPendingMessages()
at AspComet.MessageHandlers.MetaConnectHandler.HandleMessage(Message request)
at AspComet.MessagesProcessor.Process(Message message)
at AspComet.MessagesProcessor.Process(IEnumerable`1 messages)
at AspComet.MessageBus.HandleMessages(Message[] messages, ICometAsyncResult asyncResult)
at AspComet.CometHttpHandler.BeginProcessRequest(HttpContextBase context, AsyncCallback callback, Object asyncState)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

If the client is "between" polls, then a message for immediate delivery
will not be delivered to the client until the end of the next long-poll
timeout - a 10 second delay.

If the turn around for the old long-poll response to be returned, cross the
network, be processed by the client, a new long-poll request to be created,
cross the network, and processed by the server is (say) 0.1s, then there is
a gap of 0.1s every 10s where this may happen - or around 1% of the time.

Note; this happens because Client.FlushQueue() will only send the messages
if there is a current long-poll active. If there isn't, the next long-poll
opened by the client isn't flushed immediately.