Page 1 of 3 123 LastLast
Results 1 to 10 of 26
  1. #1

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

    Hi there.


    I am trying to connect to a Lightstreamer server but the connection stalls at the bind_session.txt step.


    I can replicate this behaviour in Postman, calling create_session.txt works and produces an LS_session (SessionId), but requests to bind_session.txt never return anything and always just time out. Just to be clear, we do not get any error message or anything at all. It just never responds to the request with any data whatsoever.


    In the iOS Client, this manifests as an endless cycle of connecting and disconnecting...


    Code:
    	CONNECTING
    	CONNECTED:STREAM-SENSING
    	CONNECTED:HTTP-STREAMING
    	CONNECTED:HTTP-POLLING
    	DISCONNECTED:WILL-RETRY
    	CONNECTING
    	CONNECTED:HTTP-POLLING
    	DISCONNECTED:WILL-RETRY
    	CONNECTING
    	CONNECTED:HTTP-POLLING
    	DISCONNECTED:WILL-RETRY
    	CONNECTING
    	CONNECTED:HTTP-POLLING
    	DISCONNECTED:WILL-RETRY
    	CONNECTING
    	...
    The same client connects to other Lightstreamer servers ok but just not to our production server (I believe it's an Allegro server, 5.1.1).

    For the record, the client code is super simple:

    Code:
        override func viewDidLoad() {
            super.viewDidLoad()
            
            LSLightstreamerClient.setLoggerProvider(LSConsoleLoggerProvider())
    
    
            let client = LSLightstreamerClient(serverAddress: "https://....:443/", adapterSet: ".....")
            client.addDelegate(self)
            client.connect()
        }
        
        func client(client: LSLightstreamerClient, didChangeStatus status: String) {
            NSLog(status);
        }

    I have no idea what the next debugging step would be. What would cause this? How do we debug this issue?

  2. #2
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    Please let me clarify a few preliminary considerations.

    - Lightsreamer Allegro edition standard does not support iOS client, please could you confirm that your production server is entitled with the specific optional feature?
    - Is the Adapter Set definition identical between the test servers and the production one?

    Thank you,
    Giuseppe

  3. #3
    Hi

    1. Well I know that the server does support both iOS and Android because it's working for plenty of our live users on those platforms. But I don't know how to verify this formally. But I don't get "License not valid for this Client version" (the way I do if I try to connect with nodejs for example).

    2. No, my successful connections are essentially to a local copy of Lightstreamer-example-HelloWorld-adapter-java. So the adapter set is "HELLOWORLD" for that.

    I didn't mention that I do also have some testing environments to work with that match the structure of our production server and if I try to connect to those, they behave exactly the same way as production. So I take from that that whatever this issue is it's our fault somehow.

  4. #4
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    Ok, in this case could you change the logging configuration (lightstreamer_log_conf.xml) of one of your testing server with these setting

    Code:
    	<logger name="LightstreamerLogger.connections" level="INFO"/>
    	<logger name="LightstreamerLogger.requests" level="INFO"/>
    	<logger name="LightstreamerLogger.push" level="DEBUG"/>
    and repeat the test case?

    So, we should get some more precise information from the server log file.

    Regards,
    Giuseppe

  5. #5
    Should be attached to this post.
    Attached Files Attached Files

  6. #6
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    Thank you for the log, indeed the case is quite strange.
    It seems that some replies from the sever are missed by the client. Please could you confirm that there are no network intermediaries (proxies or something similar) in the middle that can buffer in some cases the replies?

    Otherwise, please could you retry the test case after adding this settings to lightstreamer_conf.xml (under the <lightstreamer_conf> root):

    Code:
    <keepalive>N</keepalive>
    and add also this log setting:
    Code:
    	<logger name="LightstreamerLogger.requests.polling" level="INFO"/>
    Regards,
    Giuseppe

  7. #7
    Thanks for the help Giuseppe

    I've made those changes and I have another log file for you but I can still see keepalive mentioned in there ...
    Attached Files Attached Files

  8. #8
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    I confirm that it seems that the <keepalive>N</keepalive> setting was not applied.
    Please could you check the lightstreamer_conf.xml configuration file, the <keepalive>N</keepalive> should be just after <lightstreamer_conf>.

    If all seems correct to you please, repeat the test case with this additional log setting (I warn you that this is very verbose):

    <logger name="LightstreamerLogger.requests" level="INFO"/>

    In addition I am wondering if you could arrange a network sniff.

    Regards,
    Giuseppe

  9. #9
    Okay I am very confused now.

    Here is the first bit of my lightstreamer_conf.xml file:

    Code:
    <?xml version="1.0"?>
    
    
    <lightstreamer_conf>
    
    
        <keepalive>N</keepalive>
        <logger name="LightstreamerLogger.requests" level="INFO"/>
    
    
    <!--
        The following elements, subelements and attributes are consulted
        by Lightstreamer Server to setup its own configuration. Elements with
        an empty or blank value are ignored and considered as not defined at all.
        Elements described as "cumulative" can be inserted multiple times in the
        same place.
    I've attached another log of a failed connection. But it looks exactly the same to me. It doesn't look like these configuration changes are having any effect. I restarted the Lightstreamer server prior to the test, just to be sure.

    There are no other <logger> tags inside lightstreamer_conf.xml, but there are a lot of them inside lightstreamer_log_conf.xml. One of them is exactly the same as the above command. I'm not sure if statements in this file will also take effect.

    Please could you confirm that there are no network intermediaries (proxies or something similar) in the middle that can buffer in some cases the replies?
    I don't think so.

    In addition I am wondering if you could arrange a network sniff.
    Shouldn't be a problem, I'll probably work on this tomorrow.
    Attached Files Attached Files

  10. #10
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    541
    Hi abcdefg,

    I am very sorry to have been inaccurate in my instructions.
    Indeed the logger configuration is related to the lightstramer_log_conf.xml file and not to lightstreamer_conf.xml and also the suggested level was wrong.

    In lightstramer_log_conf.xml please change the level for <logger name="LightstreamerLogger.requests" level="WARN"/> to DEBUG.

    Anyway, in this log it is clear that the <keepalive>N</keepalive> setting was successful. You may notice that there are no more rows in the log file like this:

    17:01:30.930 [SERVER POOLED THREAD 1] INFO LightstreamerLogger.connections - Reused HTTP connection on "Lightstreamer HTTP Server" from 10.9.8.133:59985

    Unfortunately also in this case we could not exactly figure out why the replies to some bind requests are not send to the client.

    Some steps by which we can proceed with the investigation are:

    - Please could you priovide us with the details about the client library in use in these tests (library type and version)?

    - Repeat the test case wiht the extra log settings (in lightstreamer_log_conf.xml):
    <logger name="LightstreamerLogger.requests" level="DEBUG"/>
    <logger name="LightstreamerMonitorText" level="TRACE">

    and if possible, a network sniff.

    - Repeat the test case with a Lightstreamer server 6.0.x.

    Thank you,
    Giuseppe

 

 

Similar Threads

  1. SYNC Error on bind_session
    By shifter1 in forum Client Protocol
    Replies: 1
    Last Post: November 18th, 2013, 10:14 AM
  2. Upgraded to LS 4 and many POST bind_session.txt
    By Adrian Parker in forum Client APIs
    Replies: 2
    Last Post: November 21st, 2011, 04:03 PM
  3. Pull data from txt file to lighstreamer (NEWBIE)
    By forexinvestor in forum Adapter Protocol
    Replies: 1
    Last Post: December 23rd, 2008, 09:55 AM
  4. Trying to run LS through Https / SSL
    By wmolde in forum Client APIs
    Replies: 2
    Last Post: April 18th, 2007, 04:40 PM
  5. GETTING_STARTED.TXT doubts
    By rmusco in forum General
    Replies: 11
    Last Post: November 30th, 2006, 11:25 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 04:09 AM.