search

Comcast / sirius

A distributed system library for managing application reference data
http://comcast.github.io/sirius/
Apache License 2.0
298 stars 49 forks source link

Allow RequestHandler object to be changed #16

Closed smuir closed 10 years ago

smuir commented 10 years ago

In some use cases it may be desirable for the application developer to change the RequestHandler object that is used by Sirius. For example, if the application has multiple phases that it changes between, and each phase has a different handler behaviour.

It is possible to do this with an app-level proxy handler, but there may be advantages to supporting it natively in Sirius, especially if it is a common use case. At the minimum there should be a clear statement of the semantics of how RequestHandler methods are called that allows the app developer to safely implement a proxy, e.g., does Sirius guarantee (now and in the future) that callbacks are always made from a single thread and thus are serialised?

clinedome-work commented 10 years ago

This wouldn't be especially hard, but I'm not sure it's a direction we want to go. The configuration you pass into SiriusFactory should be considered immutable -- without tearing down Sirius and bringing it back up, there should be no real way to change it. The app-level proxy is probably the right choice, IMO.

ReqHandler calls are always serialized.

comcast-jonm commented 10 years ago

I think I'm also -1 on this enhancement, mostly due to synchronization issues. For example, there may be several in-flight updates Sirius is managing when the request to swap the RequestHandler is made. Where exactly should the swap get scheduled? I do feel like the application is in a better position to manage this.

Put another way, this enhancement doesn't add functionality the application can't easily add itself, so it's probably not worth growing the API surface for this.

smuir commented 10 years ago

I'm fine with not implementing this, but putting the burden on the app developer does require that we explicitly state (and commit to) a particular concurrency model, e.g., serialised handler calls. I don't think it's too much of a constraint on future Sirius development, although I can just about imagine a model of Sirius where callbacks were issued by multiple threads. That does seem like quite an unlikely model to arise though.