-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subscribeToPresence... sends two POST requests to AuthorizationURL #76
Comments
Hi Luke, Just wondered if you've had a chance to look at the two issues I posted. Great library by the way ... really helped me this year. |
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? |
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. |
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 [email protected] 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:](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. |
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 [email protected] wrote:
|
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)) :
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. |
I am aware this is an old issue. #####WRONG##### function function_Two() { ######GOOD########## |
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
Like I say, I've just started with it so I'm not sure if it's something I'm doing wrong.
The text was updated successfully, but these errors were encountered: