The server I'm trying to use just stalls at bind_session.txt

abcdefg

Hmm. After returning to the problem a week later, I can't reproduce my own results.

I'm getting the behaviour I stated for the 5.1.2 server, but not for the 6.0.3 any more. (I think perhaps I just got confused between the various test cases I'm cycling through.)

I understand that you are no longer "officially" supporting 5.x servers anymore, however our overcomplicated server structure will make it a difficult task to upgrade.

I believe you should be able to reproduce this issue using a 5.1.2 server and I've uploaded a test case which you can run. It should be exactly the same as your test except a slightly older version of Lightstreamer.

If you can reproduce this in any way at all, even using an outdated server, it will make me happy.

It may be that between the sniff and the Lightstreamer server there is some software component such as antivirus, firewall or similar?

Ever since I understood that the <use_enriched...> flag was involved, I've been able to reproduce the scenario using localhost:8080 like you. I'm not really using my remote test server anymore. So I believe I've removed this possibility.

Dario Crivelli

Before delving into reproducing the case, we need some clarifications.

Do you confirm that the <use_enriched_content_type> flag is important and that with <use_enriched_content_type> set to Y your testcase works also in Server 5.1.2 ?
In fact, we notice that in the configuration you sent the <use_enriched_content_type> is N.
So, can we assume that, by moving from 5.1.1 to 5.1.2 (which is straightforward) and setting <use_enriched_content_type> to Y, you have fixed your issue, as far as your operativity is concerned?

Do you mean that with Server 6.0.3 your testcase works even when <use_enriched_content_type> is N?

According to the logs included in your testcase, we see that the testcase still involves an OSX client library 2.0.1 trying to connect to a Server 5.1.2, which is not supported.
Is this the extension to 5.1.2 that you would like to be applied?

abcdefg

Do you confirm that the <use_enriched_content_type> flag is important and that with <use_enriched_content_type> set to Y your testcase works also in Server 5.1.2 ?

Yep.

In fact, we notice that in the configuration you sent the <use_enriched_content_type> is N.
So, can we assume that, by moving from 5.1.1 to 5.1.2 (which is straightforward) and setting <use_enriched_content_type> to Y, you have fixed your issue, as far as your operativity is concerned?

Locally yes. I'm trying to avoid server upgrades because our deployment scripts are ... less than fully understood.

Do you mean that with Server 6.0.3 your testcase works even when <use_enriched_content_type> is N?

I just checked again to make sure. Yes.

According to the logs included in your testcase, we see that the testcase still involves an OSX client library 2.0.1 trying to connect to a Server 5.1.2, which is not supported.
Is this the extension to 5.1.2 that you would like to be applied?

That's the behaviour I would like to test, yes, thanks.

Since the Flex client connects, but the iOS/OSX one doesn't, I thought I might be looking at a client bug. It sounds like this isn't the case. On the off-chance that it is, then a fix would be great, otherwise screw it, I'll get the wheels turning for an upgrade.

Thanks to both of you by the way.

Giuseppe Corti

Hi abcdefg,

As already said the 2.0.x versions of OS X and iOS clients are compatible since version 6.0.1 of Lightstreamer server. Use them with version 5.x could result in unpredictable behavior.
In any case I can not officially support you in using the OS X 2.0.1 client with a server 5. From my point of view should not work even the create_session.
You should consider the 2.0 client only if you're planning to go to server 6. Otherwise you should fall back to the client version 1.2.4.

By the way, I can confirm that we have replicated your test case.

Regards,
Giuseppe

Giuseppe Corti

Hi abcdefg,

Eventually we found the possible culprit of the strange behaviors you have observed.
Indeed should be the padding agreed between the client and the server.

As already mentioned the client 2.0 and server 5.0 are not compatible and so they could not agree a proper padding setting. The enrich configuration forced (as a side effect) a padding acceptable to iOS/OS X client 2.0 and that was the trick.

Just to confirm my hypothesis, pleaser could you try a 5.1.1 server with this configuration

<padding>2048</padding>

and OS X 2.0 client?

Regards,
Giuseppe

abcdefg

Yep, that does the trick!

<use_enriched_content_type>N</use_enriched_content_type>
<padding>2048</padding>

2016-09-28 10:26:30.144 OSXConnectionTesting3[42934:5980634] CONNECTING
2016-09-28 10:26:30.293 OSXConnectionTesting3[42934:5980634] CONNECTED:STREAM-SENSING
2016-09-28 10:26:30.302 OSXConnectionTesting3[42934:5980634] CONNECTED:HTTP-STREAMING

Thanks once again for your help.

Phew!

« Previous Page