river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: moving classserver port
Date Tue, 23 Nov 2010 08:32:46 GMT
This is a really interesting/good idea.  I've seen something like it
before, although HTTP port numbers weren't involved.

My only comment would be that this doesn't seem (to me) to be part of
River's remit.  What's configured, how that configuration might differ
between environments or even on hosts within the same environment, how
do you deal with failures and mistakes (what happens if two services
of the same type, with the same attributes start on the same machine
and receive the same HTTP port from the Configuration service?)

Having said that, River does provide a lot of cool stuff, but (in my
opinion) very little application-level cool stuff that can be used out
of the box.  Providing some kind of AbstractConfigurationService and
AbstractConfigurableService base classes would be a step in providing
some of that cool-stuff.

If this is a desired approach (and the more I type, the more I warm to
the idea) it'd be good to design it with the Groovy configuration
stuff in mind, thus allowing different types of configuration
behaviour to be easily swapped in/out.

Good thinking Peter.  In four paragraphs I've gone from skeptical to
"Yeah, let's do it."

On Tue, Nov 23, 2010 at 1:15 AM, Peter Firmstone <jini@zeus.net.au> wrote:
> Sim IJskes - QCG wrote:
>> On 11/22/2010 10:13 PM, Christopher Dolan wrote:
>>> Or just use port 0 and let the OS figure it out.  The only trick then is
>>> communicating the port back to the RMI codebase attribute.
>>> Chris
>> I think here we are at the heart of the problem. Deployment.
>> You have to setup everything in configuration files and then start river.
>> If you want to do this programmatically, its hard.
>> Gr. Sim
> Hmm, a Configuration service?  Eg 1000 clients might be the same machine and
> have an identity they use to request a configuration service for their
> current configuration?  Allowing their configuration to be implemented in
> one place?  We could have redundant slave configuration services too.
> I haven't thought this out, it might not be feasible, just thinking aloud.
> Cheers,
> Peter.

View raw message