Hi Conal,
Conal Tuohy-2 wrote:
>
> On 25/02/11 20:31, Leo Romanoff wrote:
>> To some extent, our current RESTful API follows this
>> idea. We use the patterns like:
>>
>> POST /service/startProcess -> would return the process id of newly
>> started
>> process
>> GET /service/process_id/state_resource_path
>> DELETE /service/process_id
>>
>> But as I mentioned, this process has a LOT OF state. Replicating its
>> state
>> between cluster nodes is very difficult and inefficient for different
>> reasons. Therefore, only the cluster node owning the process can process
>> requests related to it. And I do not see yet how your proposal helps in
>> this
>> regard. Or may be I misunderstand what you say?
>
> It seems to me that the point of a "cluster" is usually to hide the
> existence of multiple server nodes from the client. But in your case,
> this is precisely what you DON'T want to do. You actually want the
> client apps to deal with a particular server in the cluster.
>
>
I still want to hide the existence of multiple nodes in the cluster (because
I want to be able to change the number of machines or use
virtualization/migration, etc), even though all subsequent client requests
should go to a specific node. Therefore, the internal structure of the
cluster should not become transparent for our clients.
> In the scenario you gave above, your client asks the server to create a
> resource representing a "Process", and the server responds with the URI
> of the process. That URI should specify the concrete server in which the
> process runs, e.g.
>
> POST http://myserver.example.com/service/startProcess -> returns the URI
> http://myserver7.example.com/service/process22
>
> Then your client can interact with the service running on myserver7;
> monitor it, and delete it from there.
>
>
I like your idea. It is also rather similar to Jan's proposal:
> Then I think your reference to 'session' is not really the issue.
> Can't you place the node information into the URI? What is the point of
> load balancing the requests if
> they hit the same node anyway?
> Or is this a public service and needs 'normal' URLs?"
Since I don't want to expose cluster nodes explicitly in the URI using their
hostnames, I'll try to use a slightly modified approach:
- the processId that I return will contain as part of its name a unique
cluster node identifier in a non-transparent way (may be encrypted or using
some sort of a symbolic alias)
- all subsequent requests use this processId anyway and my load balancer
can have very simple pre-configured rules like "if incoming HTTP request URI
contains unique cluster node identifier of the node X then route it to the
node X"
I think this way, I can achieve what I need.
Thanks again,
-Leo
--
View this message in context: http://jersey.576304.n2.nabble.com/Providing-a-stateful-JAX-RS-service-in-a-cluster-tp6063881p6070287.html
Sent from the Jersey mailing list archive at Nabble.com.