Remote connections issues.

stephenallred

Hi,

We have both a web based and a .Net based client using Lightstreamer. Our web based client works perfectly when running locally and accessed remotely. Our .Net based client, however, functions correctly while connecting to a Lightstreamer server running on the localhost, but only receivers session data when running on a remote machine.

Both use the same or similar adapters with the same data.

Lightstreamer log:

04-Feb-10 11:25:18,218 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 7     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1113
04-Feb-10 11:25:18,219 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 7     |Starting new session: Saa342fcb258afe7aT2518219 from 192.168.1.42:1113
04-Feb-10 11:26:59,419 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 3     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1114
04-Feb-10 11:26:59,420 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 3     |Starting new session: S1f8a9b878b9f53bfT2659420 from 192.168.1.42:1114
04-Feb-10 11:26:59,619 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 2     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1115
04-Feb-10 11:26:59,620 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 2     |Starting new session: Sab45030d655a7ee9T2659620 from 192.168.1.42:1115
04-Feb-10 11:30:49,864 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 8     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1117
04-Feb-10 11:30:49,865 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 8     |Starting new session: Sb1d7cdb15c46f0b3T3049865 from 192.168.1.42:1117
04-Feb-10 11:30:50,065 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 10    |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1118
04-Feb-10 11:30:50,066 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 10    |Starting new session: Sd689c5278b407032T3050065 from 192.168.1.42:1118
04-Feb-10 11:32:31,378 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 7     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1119
04-Feb-10 11:32:31,379 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 7     |Starting new session: S19b518a3f4b225e7T3231379 from 192.168.1.42:1119
04-Feb-10 11:36:21,639 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 3     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1120
04-Feb-10 11:36:21,640 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 3     |Starting new session: S9cacf5d99f63d0feT3621639 from 192.168.1.42:1120
04-Feb-10 11:36:21,838 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 2     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1121
04-Feb-10 11:36:21,839 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 2     |Starting new session: Scf5fb8a6b3855e5aT3621839 from 192.168.1.42:1121
04-Feb-10 11:36:22,038 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 8     |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1122
04-Feb-10 11:36:22,038 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 8     |Starting new session: Sc494861aac01f818T3622038 from 192.168.1.42:1122
04-Feb-10 11:36:22,238 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 10    |Serving request: /lightstreamer/create_session.txt?LS_content_length=50000000&LS_report_info=true&LS_adapter=AdminUIAdapterSet from 192.168.1.42:1123
04-Feb-10 11:36:22,239 |INFO |LightstreamerLogger.requests     |SERVER POOLED THREAD 10    |Starting new session: Scf7ab63759b8b5a4T3622238 from 192.168.1.42:1123

Log from our .Net based application:

2010-02-04 11:48:31,118 ERROR [8]  SubscriberConnection - Unable to connect.
Lightstreamer.DotNet.Client.PushConnException: The operation has timed out ---> System.Net.WebException: The operation has timed out
   at Lightstreamer.DotNet.Client.PushServerTranslator.CallSession()
   at Lightstreamer.DotNet.Client.PushServerProxy.ConnectForSession()
   --- End of inner exception stack trace ---
   at Lightstreamer.DotNet.Client.PushServerProxy.ConnectForSession()
   at Lightstreamer.DotNet.Client.ServerManager..ctor(ConnectionInfo info, IConnectionListener listener, IServerListener asyncListener)
   at Lightstreamer.DotNet.Client.LSClient.OpenConnection(ConnectionInfo info, IConnectionListener listener)

(All firewalls etc disabled)

Any help with this would be much appreciated,
Steve

Dario Crivelli

Did you see only one occurrence of the client-side stack trace for all the attempts shown in the Server log?

It seems that the client does not even receive session data,
although the Server receives the requests for opening a new Session.
So, it's like the client can't get the answer back.

As you say that the web client works, can you check if the web client resorts to smart polling?
Alternatively, you could try forcing POLLING mode in your .NET client and see what happens.
If smart polling works, then consider that in the forthcoming release of Lightstreamer we will add the Stream-sense feature also to the .NET client library, hence you will not need to force POLLING mode to overcome the case.

stephenallred

Thanks for the quick reply.

@DarioCrivelli, Wrote: As you say that the web client works, can you check if the web client resorts to smart polling?
Alternatively, you could try forcing POLLING mode in your .NET client and see what happens.

I've forced polling on the client and it is now working, but this is obviously not idea. Could you suggest any reasons for this behaviour?

Also, the .Net example works fine remotely over the same connection without polling. The only difference I can see between our code and the example is that the example uses MixedMetadataAdapter adapters, whereas ours uses LiteralBasedProvider adapters.

Thanks,
Steve

Dario Crivelli

Streaming may be prevented by any intermediate node, typically by a proxy.
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.

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 OpenConnectioncall and, if it has not returned after this timeout, the application should configure for polling and issue OpenConnection again.

stephenallred

@DarioCrivelli, Wrote: 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.

@DarioCrivelli, Wrote: 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.

@DarioCrivelli, Wrote: 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 OpenConnectioncall 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 Alinone

Hi Stephen,

Thanks for this update, much appreciated.

Alessandro

Dario Crivelli

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.