subscriber does not work on windows

[vivekvrao]

Hey,
Thanks for creating this project. I think its sorely needed and very well made.

I find that the Subscriber is not working on windows.
I just copied your redis_subscriber.cpp example into the TEST project on windows

• loaded #pragma comment(lib,"WS2_32") and ran it.

It connects to redis makes a subscription - and shows as subscribed on redis. But the subscription callback is not called. Once in a while a single message might make it through - but never more than that. something seems to be wrong here.

Please take a look.
thanks,

[Cylix]

Hi,

Thanks for your issue, I'll have a look tomorrow by the end of the day.
I'll keep you up to date as soon as I find something.

Best

[Cylix]

Hi,

I just made some tests and I'm kind of wondering if the issue is not coming from the unofficial implementation of the unofficial redis server itself.

Indeed, when I activated the log on cpp_redis and tacopie at debug level and tried to PUBLISH something to the channel using a netcat client, I basically received nothing on my TCP client.

So I did another test: I opened one netcat from which I subscribed to a channel. Then I published to the same channel with another netcat client: nothing was received on the first client.
But then, if I tried to send some characters again from first client, I suddenly received all the pending notifications.

So, not sure, but seems like there is an issue on the server side of the unofficial redis server.

I'll have a deeper look and check if I can do something on my side.

Best

[Cylix]

Mmmh, seems like it is working fine on their redis-cli though.
Really weird.

[codekym]

I have the same problem above in Visual Studio Community 2015 Build.
Subscriber does not work on windows in my sample project.
Redis-cli is working fine.

[gidorah]

I have the same problem with basic examples. But I have a method that uses subscriber, which is also takes an object as parameter. It never misses a notification from server, here is the code, I hope it helps:

template <typename OBJECT>
void subscribe(std::string const & key, subscribe_type const & type, OBJECT shm_handler)
{
	std::string str_key = "__key*__:" + key;

	auto func_psubscribe_reply = [=](const std::string& chan, const std::string& msg) {
		std::string redis_key = chan.substr(chan.find(key));
		handle_subscriber_reply(redis_key, shm_handler);
	};

	subscriber.psubscribe(str_key, func_psubscribe_reply).commit();
}

Note: this "shm_handler" object is a class that writes subscribed values to the shared memory. So maybe somehow this class keeps subscriber alive. It is a bit messed up but you can see whole of my code at my fork of cpp_redis.

[gidorah]

When I use 'psubscribe' doesn't matter if it is able to get notifications from subscribed channel or not, "pubsub numpat" command returns '1' from another client.

But for 'subscribe', " pubsub numsub" always returns '0' and of course it never gets the messeage from subscribed channel. My bad, "pubsub numsub" returns '1'

[Cylix]

Sorry for the time to reply, was really busy this last week.

Seems like the issue is coming from the WSAPoll that does not wake-up while it should.
When I set a breakpoint with the current -1 timeout, I can easily see that poll is not waked up.
But if I switch to a timeout of 1000, I end up having my notification (with possibly some delay, the time that the timeout expire).

My guess would be that for some reason I do not set the appropriate events that WSAPoll should listen to. This might happen if my self-pipe-trick implementation does not work as expected on windows and lead to a WSAPoll call which is never updated with new events to listen to.

There is also some reported bugs about WSAPoll itself, but I doubt for now that it is the cause, so will check my code first.

[Cylix]

Ok, I think I find a patch.
The bug was a tricky one, I'll submit a fix and explanation soon.

[Cylix]

So basically the issue was due to the way events are registered before calling WSAPoll.

We do register for a read event if a socket has been assigned a read_callback AND if a socket read_callback is not currently being executed.

In the code, we do notify the poll function to wake it up every time we update this callback (either to set it, unset it or reset it).
However, we do not notify when the read_callback finished o execute.

This leads to the possible situation:

1. start to execute read_callback
2. start a new poll while the callback is being executed: because the callback is executing, we do not listen for read events
3. callback finishes to execute: we keep polling without notifying that the state has changed and that we might need to listen to additional events.

So the bug has been easily fixed by notifying the poll when the callback finished to execute.

I made the change for the windows implementation.
I guess this might also impact the unix implementation (though nothing has been reported yet concerning that one and I could not reproduce it on my side), so I'm also going to provide the same fix for unix.

[Cylix]

Fix deployed on master and released under v1.3.1.
Feel free to re-open this issue if necessary.

Best :)

[vivekvrao]

works, thanks for the solution!