Remote connections issues.

[stephenallred]

Streaming may be prevented by any intermediate node, typically by a proxy.

It's a direct connection with only a network switch in between. There are no firewalls or proxies that could be blocking streaming.

If you confirmed that the same client and the same Server can work in streaming with one Adapter Set and can't with another one, that would be really weird.
There must be some other difference between the two cases.

The example .Net code works correctly across the same connection.

Anyway, as said, in the forthcoming release of Lightstreamer (.NET client library 1.4), OpenConnection, when configured for streaming, will check internally for streaming feasibility and will resort to Smart Polling if needed.
For now, your application code should setup a timeout check on the OpenConnection call and, if it has not returned after this timeout, the application should configure for polling and issue OpenConnection again.

This is obviously not ideal. Because of the nature of our .Net client it will be used within a properly managed network, so it would in fact be preferable that the software failed to connect rather than resorting to polling.

Can you think of anything that could be wrong in our code that could be causing this behaviour?

Many Thanks,
Steve

[Mone]

Hi,

maybe a server log would help understanding the situation. Is it possible for you to send such log?
In that case set the level of the LightstreamerLogger.requests category to INFO (its default) do your tests and send us the log (please include both a test with the .NET client and one with the Javascript one so that we can compare them).

This is obviously not ideal. Because of the nature of our .Net client it will be used within a properly managed network, so it would in fact be preferable that the software failed to connect rather than resorting to polling.

You'll be able to disable such behavior

[stephenallred]

I've been meaning to post a quick heads up as to what was going wrong since we solved the issue (on the Friday of the week of the last post here, sorry about the delay). .Net has a limit on the number of external connections but not internal ones. As such, when running locally all the connections could connect. Running external mean only the first 2 (the .Net default on a 32 bit Vista machine) connections were allowed. The rest received a .Net exception which the Lightstreamer library was catching and throwing it's own (which is why it wasn't trivial to find the solution.). To solve this we increased the .Net limit for external connections. In future we will move to a single connection for all subscriptions.

[Alessandro]

Hi Stephen,

Thanks for this update, much appreciated.

Alessandro

[DarioCrivelli]

About .NET library exception management, which unfortunately has been misleading for you,
I would like to clarify that the source system exception is available to application code
as the "InnerException" property of the PushConnException received.