Le 14/01/2014 21:24, Martin Sustrik a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Laurent,1. Add new socket option, say NN_REQ_SCHEDULER, with possible values of NN_REQ_ROUND_ROBIN (current implementation, the default) and NN_REQ_STICKY. The latter, when applied to a REQ socket would cause requests from the same client to be sent, if possible, to the same worker. If the old worker is not available, the message will be sent to a different worker.In my use case, if the message is sent to a different worker, it will fail as it is stateful. So the best way here is to drop the message IMO. I think NN_REQ_STICKY is useful only for statefull messaging. And in statefull processing, reassigning one peer to another fails anyway, or you have to add some management to reinitialize the exchange from the beginning. It is useless complexity. It is not only performance optimisation to use cache data as most as possible. Here, I have no mean to recover from the new worker. But probably there is the need for two different behaviours of NN_REQ_STICKY. I will do it with a simple drop.The behaviour that I have described is actually used in some large-scale applications. The request is routed to a worker which accesses the shared data using some kind of distributed DB/filesystem (think of GFS). The filesystem either has the data cached locally or has to load them from a different node. By assigning requests from the same client to the same worker you are maximising the chance of the former and thus improving the efficiency of the system. In your use case, I would suggest that the worker that doesn't have the data just returns a reply saying "no data" at the application level. There's no much point of handling the check on nanomsg level IMO.
Possibly an addtional option: NN_REP_RECOVERY: NN_REP_REASSIGN or NN_REP_DROP
Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1ZzqAAoJENTpVjxCNN9Y8zoH/3PSnK9e8/dkYIEADRNxhP+j VZrsbyXYsY0e7+PAeUaloqZRyNRzTdqG482gA5w2QUpcQG5yfUD664F3/PKPtWAK 6djyiolYWeoHRQtqer1oYMD8eJELz59DJegD9nf1AY3j1iCIxx31CGcHs9Fqj8Gj HudH5SmlAv1J8SYdnpVh5RSlMVWaVd8kIHQcJ8uvFDrEBcJnHWcbPYOCZKI8rtTa l6EurAnNVH5VIsQZvHfkMwAb6SgO9Z2t5a0XStqiaSpt5KQtN9kPj8QhRhnDB5wt vlZVVyqnmetqIH42Bh16u+J5uK5Sz7yuj611jcH8MySSd4+GaUmdoMK+mI0+aUI= =gNvX -----END PGP SIGNATURE-----
