cancel method of subscriptions and publications does not work synchronously

[GoogleCodeExporter]

The `cancel` methods of subscription and publication objects currently _appear_ 
to be working synchronously, but they are actually operating asynchronously, by 
sending an async message to the discovery actor.

In practice, this means that even after cancelling the publication for an 
exported object, the exported object can still be discovered.

Proposed fix for now is to turn pub.cancel() into a sync_event such that the 
calling actor blocks until the discovery actor has actually removed the 
publication. This is not ideal because the discovery actor can actually do 
remote communication, so there could be a high latency in processing the 
actor's cancel() request.

In the extreme case, if the discovery actor _itself_ (by overriding the 
isSubtypeOf test on a published/subscribed type tag) itself wants to take a 
publication object offline (highly unlikely), the discovery actor could now 
deadlock.

Therefore, a safer alternative would be to have cancel() return a future, or 
even better, to enforce that cancel can only be called asynchronously. (one 
could then use futures to synchronize on the fact that the publication was 
taken down, like so: when: pub<-cancel()@FutureMessage becomes: { |_| /* pub 
taken offline for sure */)

The issue came up in the context of unit testing, where the next test can only 
be started after exported objects created in the previous test have been 
cancelled.

Original issue reported on code.google.com by tvcut...@gmail.com on 6 Apr 2011 at 1:59

[GoogleCodeExporter]

Fixed in trunk r2782

Original comment by tvcut...@gmail.com on 8 Apr 2011 at 8:17

• Changed state: Fixed

[GoogleCodeExporter]

Thinking about this issue some more, I believe my earlier diagnosis was wrong.

`pub.cancel()` indeed sends an asynchronous request to the local discovery 
actor to take the publication offline. However, any call to when:discovered: 
after the call to `pub.cancel()` has returned must necessarily also enqueue a 
request in the discovery actor, which will always be in the queue after the 
earlier request. Hence, these later when:discovered: requests will only be 
processed by the discovery actor when the earlier request to take the pub 
offline was already processed.

Fix reverted in trunk r2787

Original comment by tvcut...@gmail.com on 11 Apr 2011 at 12:53

• Changed state: WontFix