Comment 5 for bug 686048

Hey,

The reason I don't want to synchronize the calls in my messaging layer is that I would have to know which methods are synchronous. I can read the spec file and hardcode this knowledge into my code but I would rather not do this. The layer using the library should not be concerned about its implementation details, it is just a good design principle to follow.

I agree the idea with DeferredLock is missed, fact is that if I knew how to fix it cleanly myself we wouldn't be having this discussion. So maybe lets attack this problem from the different side ?

The response is fetched from TimeoutDefferedQueue, which is implemented inside the txAMQP. Maybe lets substitute it with something which would inherit from this class ? Instead of calling get() method, lets use get(id), where id is a index of response method we are waiting for. It will fire the deferred only for selected message. This seems to be clearer solution than re-putting message back to the queue, which I'm doing know (I'm talking about the diff attached). Although I think that such approach may just allow calling more than one synchronous message in time, which I consider a nice feature. What weak sides of this approach do you see ?

One more issue nags me... What would happen if I start the synchronous call and receive the response for get() (the one called with the consumer_tag) while waiting for response. Is this situation different than the one we are discussing?

Cheers,
MK