subscribeToPresence... sends two POST requests to AuthorizationURL

[mattglover]

I've just started to investigate Presence channels using libPusher and noticed that the below call results in 2 POST requests from libPusher.
This is confirmed from server logs and Pusher's debug console

// Presence Channel
    [self.pusherClient setAuthorizationURL:[NSURL URLWithString:PUSHER_PRESENCE_AUTH_URL]];
    self.presenceChannel = [self.pusherClient subscribeToPresenceChannelNamed:PARTY_ID delegate:self];

Like I say, I've just started with it so I'm not sure if it's something I'm doing wrong.

[mattglover]

Hi Luke,

Just wondered if you've had a chance to look at the two issues I posted.
I'm wondering if I'm doing something wrong.

Great library by the way ... really helped me this year.
Matt

[lukeredpath]

I can't think of any reason why two authorization requests should be fired - are you certain that your code isn't being called twice?

[mattglover]

I did wonder also, but no ... the following code is only being called once

// Presence Channel
    [self.pusherClient setAuthorizationURL:[NSURL URLWithString:PUSHER_PRESENCE_AUTH_URL]];
    self.presenceChannel = [self.pusherClient subscribeToPresenceChannelNamed:PARTY_ID delegate:self];

and yet I see 2 requests, at the same time, hitting my authorisation URL (checking the apache logs) .. and subsequently 2 requests to join the channel on Pusher which means getting a 'CLIENT ERROR : Existing subscription to channel presence-Party12345' for the 2nd attempt, in the Pusher Debug Console.

[lukeredpath]

Are you able to put a breakpoint in the delegate and try and trace those calls back to their origin?

On 29 Nov 2012, at 15:59, Matt Glover notifications@github.com wrote:

I did wonder also, but no ... the following code is only being called once

// Presence Channel
[self.pusherClient setAuthorizationURL:[NSURL URLWithString:PUSHER_PRESENCE_AUTH_URL]];
self.presenceChannel = [self.pusherClient subscribeToPresenceChannelNamed:PARTY_ID delegate:self];
and yet I see 2 requests, at the same time, hitting my authorisation URL (checking the apache logs) .. and subsequently 2 requests to join the channel on Pusher which means getting a 'CLIENT ERROR : Existing subscription to channel presence-Party12345' for the 2nd attempt, in the Pusher Debug Console.

—
Reply to this email directly or view it on GitHub.

[mattglover]

Ok ... it looks like the following method is being called twice.

[PTPusher subscribeToChannel:]

1st time :

[PTPusher subscribeToPresenceChannelNamed:delegate:]

Called from my [RootViewController pusher:connectionDidConnect:](PTPusherDelegate callback)

2nd time :

[PTPusher pusherConnectionDidConnect:]

Called from an occurrence of [PTPusherConnection webSocket: didReceiveMessage:]; which calls [PTPusher pusherConnectionDidConnect:] that loops through it's dictionary of PTPusherChannels (channels) and subscribing to each of them.

[lukeredpath]

Ok, so there is a weird race condition here.

You don't normally have to wait until the pusher client is connected before subscribing to channels (like you are doing), you can do so immediately and Pusher will process the subscriptions when it connects automatically.

However, it's not unreasonable that an implementation of the pusher:connectionDidConnect: delegate method might try and subscribe.

It looks like the fix here is for the client to loop through its subscriptions before firing off the delegate callback.

Alternatively, it might be better to check if a channel is in a subscribing state before trying to call subscribe.

On 29 Nov 2012, at 19:18, Matt Glover notifications@github.com wrote:

Ok ... it looks like the following method is being called twice.

[PTPusher subscribeToChannel:]
1st time :

[PTPusher subscribeToPresenceChannelNamed:delegate:]
Called from my RootViewController pusher:connectionDidConnect:

2nd time :

[PTPusher pusherConnectionDidConnect:]
Called from an occurrence of [PTPusherConnection webSocket: didReceiveMessage:]; which calls [PTPusher pusherConnectionDidConnect:] that loops through it's dictionary of PTPusherChannels (channels) and subscribing to each of them.

—
Reply to this email directly or view it on GitHub.

[mattglover]

I did try to place the following in [PTPusher pusherConnectionDidConnect:](if this it what you meant by checking the subscribing state)

    if(![channel isSubscribed]) {
      [self subscribeToChannel:channel];
    }

however that had no effect as at the time of calling each channel was not subscribed.

I do now have a better understanding of the flow in which to subscribe to a channel (and configure event binding(s)) :

1. Instantiate an instance of pusherClient
2. Configure pusherClient with presenceAuthURL and presenceChannel
3. Configure pusherClient with eventBinding(s)

and not doing the config in the pusher:connectionDidConnect: (delegate callback).

It makes a lot more sense to use this approach when setting up my pusherClient and it's subscriptions (and eventBindings)

Thank you for taking the time to go through this .. please feel free to close this issue if you wish.

[osc2nuke]

I am aware this is an old issue.
But i would like to give some feedback on this.
The same problem happened to me in a JavaScript environment.
The solution i found was , if use a main connector, in javascript case:

#####WRONG#####
var pusher = new Pusher('XXXXXXXXX');
function function_One() {
//your stuff for auth url and binding
}

function function_Two() {
//your stuff for auth url and binding
}
#######################
and use that for all possible current and new connections, the error occurs.
However when set a new Pusher in each "function" the error is gone.

######GOOD##########
function function_One() {
var pusher = new Pusher('XXXXXXXXX');
}
function function_Two() {
var pusher = new Pusher('XXXXXXXXX');
}
######################