[Clustering Development] New message: "Re: Partition and Node identities"
by David Lloyd
JBoss development,
A new message was posted in the thread "Partition and Node identities":
http://community.jboss.org/message/529464#529464
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> mailto:bstansberry@jboss.com wrote:
> Re: the extra properties; what you say makes sense: jboss.host.qualified.name and jboss.host.name are useful whether or not they end up as part of the server identity.
OK, then pending a final review in jboss-dev I'll plan on setting this up.
> mailto:bstansberry@jboss.com wrote:
>
> A problem with using defaults is the node name leaks outside the data center, and if the default is used that means information about the server configuration is leaking. For example, the node name would become the logical value for the jvmRoute used by mod_jk and mod_cluster, and that ends up being appended to the session id for web sessions, which anyone can look at in a browser.
This is a good point. If we make jvmRoute configurable and default to node.name (yeah, that's a lot of defaulting) then at least it can be "hardened". Alternately, using a short hex- or base64-encoded hash of the node name plus a configurable (cluster-wide?) salt might be workable too. Or some combination thereof? In the meantime we can "punt" the issue and just force manual configuration until/unless a satisfactory solution is found.
> So, defaults are convenient but leak information. Part of my thinking on requiring their configuration once the domain configuration is in place is the inconvenience is less -- you set up your configuration once and re-use it; you don't have to retype -Djboss.node.name=xxx every time.
That seems like a reasonable plan to me. For 6, set up all the properties in bootstrap; for 7, generate them from the domain configuration.
> The previous discussion around this basic topic is at http://community.jboss.org/thread/91830?tstart=60
>
> Besides the use cases listed on that thread, JBossTS also needs a unique integer id for each server on the same host: http://community.jboss.org/thread/145892?start=0&tstart=0
I don't think we can solve the JBossTS case with a node name solution. A hash wouldn't suffice, because administrators may want more direct control over the port and we probably can't avoid collisions in any case. Apart from that, there's not a lot of options for getting from a node name to a port number, let alone an unbound one.
JBM is a similar issue, though it's possible we could get away with a hash in this case. Maybe JBM won't matter though. Not yet sure if HornetQ uses a peer ID of some sort, but I'm inclined to take the same approach: if they use a name *and* the name isn't security sensitive, default to the node name, otherwise, solve later.
Otherwise, everything I'm reading in these other threads indicates that I should be able to move forward with this idea, would you agree?
P.S. I also found http://community.jboss.org/thread/90161?tstart=0
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529464#529464
16 years, 1 month
[Clustering Development] New message: "Re: Partition and Node identities"
by Brian Stansberry
JBoss development,
A new message was posted in the thread "Partition and Node identities":
http://community.jboss.org/message/529446#529446
Author : Brian Stansberry
Profile : http://community.jboss.org/people/bstansberry@jboss.com
Message:
--------------------------------------------------------------
> mailto:david.lloyd@jboss.com wrote:
>
> Yeah, I think that no matter what, if someone is running two instances on the same machine, they'll have to distinguish the node name somehow. The case I was describing to Jaikiran was the case where there are two machines with instances bound to 0.0.0.0 in the same cluster - using the name of the bound interface would not work in this (common) case.
DOH! Yes, of course.
Re: the extra properties; what you say makes sense: jboss.host.qualified.name and jboss.host.name are useful whether or not they end up as part of the server identity.
Even if in AS 7 we force people to specify a name, jboss.node.name is still a useful way for users to access that value.
A problem with using defaults is the node name leaks outside the data center, and if the default is used that means information about the server configuration is leaking. For example, the node name would become the logical value for the jvmRoute used by mod_jk and mod_cluster, and that ends up being appended to the session id for web sessions, which anyone can look at in a browser.
So, defaults are convenient but leak information. Part of my thinking on requiring their configuration once the domain configuration is in place is the inconvenience is less -- you set up your configuration once and re-use it; you don't have to retype -Djboss.node.name=xxx every time.
The previous discussion around this basic topic is at http://community.jboss.org/thread/91830?tstart=60
Besides the use cases listed on that thread, JBossTS also needs a unique integer id for each server on the same host: http://community.jboss.org/thread/145892?start=0&tstart=0
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529446#529446
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-243 or change deployment's relative order"
by Ales Justin
JBoss development,
A new message was posted in the thread "JBDEPLOY-243 or change deployment's relative order":
http://community.jboss.org/message/529405#529405
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> > They want a -properties.xml to be deployed as a -service.xml
> > but for the -properties to go first in the REAL stage
> > so it can set the system properties before the mbeans
> > are created.
> Currently we don't order components -- with this new feature we will have to,
> otherwise we cannot order deployments with multiple matchings.
> e.g. both -properties.xml and -service.xml in the same sub-deployment
This is now done.
There is a helper method on AbstractDeployer
/**
* Change relative order on unit.
*
* @param unit the deploymenty unit
* @param relativeOrder the relative order
*/
protected static void changeRelativeOrder(DeploymentUnit unit, int relativeOrder)
{
if (unit instanceof DeploymentUnitExt)
{
DeploymentUnitExt ext = (DeploymentUnitExt) unit;
ext.changeRelativeOrder(relativeOrder);
}
}
which changes the relative order of given DeploymentUnit, while also notifying its parent of the change.
So, the next time you invoke any of the getters on the parent -- getChildren or getComponents -- those are re-ordered.
If one wants to keep the order consistent through out the deployment lifecycle, it must also reset the value to previous at undeploy.
e.g. we change the order 1st time, using it in some X deployer, then we change it the 2nd time, for Y, expecting both to hold also on undeploy
If there were multiple such changes, my guess is it would probably be hard to keep things under control.
But I doubt there will be more than 1-2 changes in the whole lifecycle.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529405#529405
16 years, 1 month
[Clustering Development] New message: "Re: Partition and Node identities"
by David Lloyd
JBoss development,
A new message was posted in the thread "Partition and Node identities":
http://community.jboss.org/message/529398#529398
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> mailto:bstansberry@jboss.com wrote:
>
> I was out yesterday; sorry for slow reploy.
>
> 100% agree we need a unique name for nodes, and the -b value isn't a good default, at least not if -b is 0.0.0.0. I'll dig up a link to an earlier thread about this general topic that kind of died out. This touches on lots of areas, so I suspect this discussion will end up moving to the jboss-development list.
>
> I don't think it's the end of the world if people have to actually specify the name if they want to run two instances on the same machine both bound to 0.0.0.0. They'd have to set -Djboss.service.binding.set=xxxx and -Djboss.messaging.ServerPeerID=y on at least one node anyway, so it's not like their startup command was totally trivial and now they are forced to add complexity.
Yeah, I think that no matter what, if someone is running two instances on the same machine, they'll have to distinguish the node name somehow. The case I was describing to Jaikiran was the case where there are two machines with instances bound to 0.0.0.0 in the same cluster - using the name of the bound interface would not work in this (common) case.
> mailto:bstansberry@jboss.com wrote:
>
> I think when we move to a proper domain model we should require each server instance in the configuration to have a name. For that reason also, I don't think driving people in some cases to actually configure the name is the end of the world. Actually, that's the one thing that concerns me in your proposal for determining the name, which otherwise sounds fine: it introduces 3 system properties. If in a future domain configuration people are just required to do something like:
> <server name=AS1...
>
>
>
>
> then for AS 6 we've probably introduced 2 configuration system properties that will disappear in AS 7?
In my research, I've seen enough people struggle to get ahold of the system's host name that it's my belief that that is something we should be providing anyway, if we can get it. This way, all the various "tricks" for getting the host name that crop up over time can be centrally located. Think of it as added value (if only a little tiny bit). So I think keeping a pair of host name properties is something that we would have no reason to get rid of.
In the future domain configuration scenario, it might still be useful for any per-host configuration to have a default server name as well. I really think that many administrators are just going to use their server host name for this anyway. The only time you should be *required* to specify a server/node/host name is when you're not talking about your own. Either way, again it might be a handy thing if users could always count on getting the node's name from a property.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529398#529398
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: Deployment lazyResolve and lazyStart"
by Ales Justin
JBoss development,
A new message was posted in the thread "Deployment lazyResolve and lazyStart":
http://community.jboss.org/message/529396#529396
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> I propose we add a new META-INF/jboss-deployment.xml which would be some generic
> metadata for this kind of processing and other possible deployment control parameters.
Yeah, this would definitely be needed / useful -- for MC/AS boot time.
> <!-- Deploy this deployment in the described stage initially - i.e. no classloader -->
> <required-stage>DESCRIBE</required-stage>
>
> <!-- Only create the classloader when somebody wants to import our package or module -->
> <lazy-resolve/>
I guess the usage of the 2nd <lazy-resolve> would mean required-stage beyond DESCRIBE doesn't make sense.
Same for <lazy-start> if the required stage is set to REAL or past.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529396#529396
16 years, 1 month
[Clustering Development] New message: "Re: Partition and Node identities"
by Brian Stansberry
JBoss development,
A new message was posted in the thread "Partition and Node identities":
http://community.jboss.org/message/529392#529392
Author : Brian Stansberry
Profile : http://community.jboss.org/people/bstansberry@jboss.com
Message:
--------------------------------------------------------------
I was out yesterday; sorry for slow reploy.
100% agree we need a unique name for nodes, and the -b value isn't a good default, at least not if -b is 0.0.0.0. I'll dig up a link to an earlier thread about this general topic that kind of died out. This touches on lots of areas, so I suspect this discussion will end up moving to the jboss-development list.
I don't think it's the end of the world if people have to actually specify the name if they want to run two instances on the same machine both bound to 0.0.0.0. They'd have to set -Djboss.service.binding.set=xxxx and -Djboss.messaging.ServerPeerID=y on at least one node anyway, so it's not like their startup command was totally trivial and now they are forced to add complexity.
I think when we move to a proper domain model we should require each server instance in the configuration to have a name. For that reason also, I don't think driving people in some cases to actually configure the name is the end of the world. Actually, that's the one thing that concerns me in your proposal for determining the name, which otherwise sounds fine: it introduces 3 system properties. If in a future domain configuration people are just required to do something like:
<server name=AS1...
then for AS 6 we've probably introduced 2 configuration system properties that will disappear in AS 7?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529392#529392
16 years, 1 month