Method "openConnectionWithInfo:" Blocking the Thread forever with no Exeption [iOS]

Hello.

I found out the following behaviour in my app:

I open connection:

Code:

---

self.client = [LSClient client];


LSConnectionInfo *connectionInfo = [LSConnectionInfo connectionInfoWithPushServerURL:_url
                                                      pushServerControlURL:nil
                                                                      user:_userName
                                                                  password:_password
                                                                  adapter:_adapter];

@try
{
    [_clientopenConnectionWithInfo:connectionInfo delegate:self];
}
@catch (LSPushServerException *exPushServer)
{
}
@catch (LSPushConnectionException *exPushConn)
{
}

---

But if I use wrong crendentials it never connect or through any exception. And the thread is blocked.
What shall I do?

Thanks in advance.

Hello,

you should receive an asynchronous exception on the clientConnection:didReceiveServerFailure: delegate callback. You can release the thread that is opening the connection by contextually calling closeConnection. E.g.:

Code:

---

- (void) clientConnection:(LSClient *)client didReceiveServerFailure:(LSPushServerException *)failure {
        NSLog(@"Server Failure received: %@", failure);

        [_client closeConnection];
}

---

Let us know if you need further help.

Yes. you are right.
I am receiving asynchronous exception on the clientConnection:didReceiveServerFailure:

but in your example it says:
// The LSClient will reconnect automatically in this case.

And what happened if we get this call after any other failure and closeConnection? We will not subscribe any more unless do all login logic from the beginning?

I'm not sure I understand your question properly, but le me explain a bit more how it works.

The openConnectionWithInfo will substantially continue trying to connect until either it succeeds or you interrupt it. It is a synchronous operation, but you can actually treat it as an asynchronous one: you run it on a background thread and forget about it. You get notified of the outcome of each tentative connection, via the delegate, and there is where you decide what to do.

The didReceiveServerFailure event carries an LSPushServerException object, which in turn carries an errorCode. This code is provided by the server, and in some cases even by your Metadata Adapter. You may decide what to do based on this code, or you may count the number of tentative connections, or whatever. All you have to know is that if you call closeConnection it will stop trying, if you don't it will continue trying (with the notable exception of didEndWithCause).

If you react by closing the connection, then yes: you have to reopen the connection from the beginning and redo all subscriptions. But checking the condition appropriately should let you limit this reaction to when it is strictly necessary (e.g. if credentials are wrong, and not if you have a network glitch).

well. to be honest.
I used to create my own serial queue for LightStreamerConnection stuff.
so it was blocked.
now I use the global concurrent queue:

Code:

---

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

        @try
        {
            [_client openConnectionWithInfo:connectionInfo delegate:self];

        }
        @catch (LSPushServerException *exPushServer)
        {
        }
        @catch (LSPushConnectionException *exPushConn)
        {
        }


    });

---

so that global queue is blocked while connecting with wrong credentials.

Then I reconnect and I don't know what is happening to it.
Anyway I don't see any previous blocks.


and secondly, I'm not receiving didReceiveServerFailure:
I receive didReceiveConnectionFailure
with message

Code:

---

Connection failure: Connection timed out


---

with no errorCode because it is LSPushConnectionException

so if I would use my serial queue when shall I call closeConnection?

If you see a callback to didReceiveConnectionFailure, instead of didReceiveServerFailure, and you are sure the issue is with credentials, then you may be incurring in a bug we have recently fixed.

A version containing the fix has not yet been released, but if you contact support@lightstreamer.com, specifying the Server version you are using, I can provide you with a link to an update version of the client library.