Reconnect to new publisher doesn't reestablish subscriptions
Description
Scenario: wuserver example from guide, with publisher subscribing to multiple zipcodes.
When the subscribers set multiple SUBSCRIBE options, it works fine on the first connection to the publisher, however if the publisher restarts, when the subscriber magically auto-reconnect, they only seem to reconnect with the alphabetically greatest SUBSCRIBE filter, thus they only get one type of message from the new publisher...
Run this with the wuserver.c (from zmq guide), and watch it as it pulls out 10001 and 10002 zipcodes, then kill and restart the wuserver (leave client running so it reconnects to new server). Now it is only returning 10002 zipcodes.
If you swap the subscribe order, it still only returns 10002, or whatever the "highest" filter is.
Scenario: wuserver example from guide, with publisher subscribing to multiple zipcodes.
When the subscribers set multiple SUBSCRIBE options, it works fine on the first connection to the publisher, however if the publisher restarts, when the subscriber magically auto-reconnect, they only seem to reconnect with the alphabetically greatest SUBSCRIBE filter, thus they only get one type of message from the new publisher...
Minimal test case: https://gist.github.com/norganna/7461882
Run this with the wuserver.c (from zmq guide), and watch it as it pulls out 10001 and 10002 zipcodes, then kill and restart the wuserver (leave client running so it reconnects to new server). Now it is only returning 10002 zipcodes.
If you swap the subscribe order, it still only returns 10002, or whatever the "highest" filter is.