[Design of JBoss internal QA (Test Suite)] - Re: Testsuite issues with multicast routing (JBAS-4939)
by akostadinov
Let me summarize the issue again. On RHEL 4U4 and below seems like locally sent multicast messages are received if listener is bound to the same interface as sender no matter if multicast route points to another interface.
On RHEL 4U5 and above that is not the case so if sender and receiver are bound to the same interface but that is not the one with multicast route set through, receiver can't see anything. That is doubtfully sane.
I think that exactly is causing the server bound to localhost to be unable to see its sent messages. So even if IP_MULTICAST_LOOP is just a hint, we have to set it anyway as long as we rely on that behavior and have to request it. I suggest we try that first to see if it will fix that particular issue.
To make things work now, both servers have to bind their multicast sockets (only the multicast ones) to the same interface which mcast route goes through. For me that is sometimes inconvenient sometimes and error prone.
I don't know how much sense does it make for JGroups itself to to bind or not bind multicast sockets to particular interface, but specifying interface is bad for JBoss AS manageability. Imagine server administrator is managing server interfaces and configures things to go through another one. That way the AS server will stop working properly.
On the other hand if JBoss multicast socket is not bound to specific interface, it is highly unlikely that produce any issues. And even if it does in very specific cases, the user can specify interface manually.
IMHO the safe choice is to not specify any interface for mcast socket and that will produce the "just work" feeling when one tries to run the test suite. I know some clients like to run the test suite locally and not having issues with it will make them more confident in JBoss AS quality. My feeling is that we'll have less issues with hudson runs as well ;)
So two things we can do:
1. Ignore and disable noip run
or
2. Try if IP_MULTICAST_LOOP fixes one of the issues *and* disable binding to specific interface for mcast sockets unless user requested that.
P.S.
anonymous wrote :
| On dev90 when a server is bound to localhost? We already established that the problem does not exist on qa01. This is an important question -- if clustering tests work on dev90 with 4.2 but not with AS 5, there is something more we need to understand.
|
Difference between dev90 and qa01 if that one is RHEL 4U5 and the other 4U4. I will try clustering tests of AS 4.2 on dev90 with node0=localhost
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102139#4102139
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102139
18 years, 5 months
[Design of JBoss internal QA (Test Suite)] - Testsuite issues with multicast routing (JBAS-4939)
by bstansberry＠jboss.com
Continuing discussion from http://jira.jboss.com/jira/browse/JBAS-4939
"Alexander Kostadinov" wrote :
| NOTE: JBoss 4.2 cluster tests pass even when one node is bound to localhost
|
On dev90 when a server is bound to localhost? We already established that the problem does not exist on qa01. This is an important question -- if clustering tests work on dev90 with 4.2 but not with AS 5, there is something more we need to understand.
anonymous wrote :
| Solutions:
| 1. Use only IPs on the same interface that multicast route goes through
|
Dimitris in the JBAS-4939 description says "Eventually, we should get rid of the 'noip' run." Sounds like you guys are saying the same thing -- don't use -b localhost. I have no objection, as long as we can confirm that there is no change between JGroups 2.4.1.x (AS 4.2) and JGroups 2.5+ (AS 5) that we're sweeping under a rug.
I don't see any major QA benefit to running tests bound to localhost; real servers are not likely to run that way. Seems to me that the default testsuite behavior of binding one node to localhost and one to the machine name is just a convenience for developers; no reason QA servers should use that default. (And it's not even a real convenience for devs if the dev uses windows or, it seems, RHEL 4U5+).
anonymous wrote : 2. Disable the default behavior to bind the socket to an interface but let OS choose the default one. If user forces the socket to be bound to specific interface, then bind to it. IMHO that is how things should work. And we will avoid the need user to mess with multicast configuration and adding IPs to be able to run the test suite.
|
Please open a thread on Clustering Dev forum to discuss. What you're saying makes sense with respect to running the testsuite, but there are other issues to consider that go well beyond the scope of this JIRA.
anonymous wrote :
| The other issue of server start-up being very slow because messages sent are not seen by the sender I think that is somehow related to the above one issue and the change in behavior after RHEL 4U4. So one of the above hopefully fix that:
Yes, this is absolutely correct. When the JGroups channel cannot receive its own multicast messages, it's FLUSH protocol is blocking waiting for them for 15-20-30 seconds. This happens several times during the course of startup and shutdown.
An issue I need to explore with the JGroups team is whether we can just make the channel connection (and hence server start) fail altogether in this situation.
anonymous wrote : set the socket option IP_MULTICAST_LOOP if not already set
Per the java.net.MulticastSocket javadocs this is only a hint to the underlying platform, so it's not reliable. I'll let Bela comment beyond that. In any case it only solves part of the problem -- multicast communication has to work to the other nodes, not just receipt of ones own messages.
anonymous wrote : And no, setting multicast route through lo is not a solution because that way mcast messages will be seen on the local loopback listener but not by the listener on eth#
|
Fair enough. But this and your description of the RHEL 4U5+ behavior implies that in RHEL 4U5, multicast can only work on a single interface in a machine, which seems strange.
Bottom line, IMHO these testsuite should be run with node0 bound to $MYTESTIP_1 and node1 to $MYTESTIP_2.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4102088#4102088
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4102088
18 years, 5 months
[Design of POJO Server] - Re: Issues with EJB2 ClusterConfigMetaData
by bstansberry＠jboss.com
"scott.stark(a)jboss.org" wrote : "bstansberry(a)jboss.com" wrote :
| | 1) Class exposes properties home(bean)LoadBalancingPolicy. DTD says they should be home(bean)LoadBalancePolicy (Balance not Balancing).
| |
| | That's a simple fix I've already made in my workspace; please advise if I should check it in; don't want to step on people.
| |
| fine, in the metdata project right?
|
Yes.
"scott.stark(a)jboss.org" wrote :
| "bstansberry(a)jboss.com" wrote :
| | 2) The way ClusterConfigMetaData.determineHome(Bean)LoadBalancingPolicy() work, you only get the default policy if you added a cluster-config element to your bean declaration in jboss.xml. If the ClusterConfigMetaData came from a container-configuration, you *don't* get any default. You get null unless the value was specifically set in the relevant container-configuration/cluster-config element. This leads to test failures. A simple workaround to fix the test failures is to add the default policies to standardjboss.xml.
| |
| The default really should come from the container config. There still is too much logic in the ClusterConfigMetaData, and in fact I don't think we should be associating the ClusterConfigMetaData with a JBossEnterpriseBeanMetaData instance to figure out defaults based on bean type. We need a merge(ClusterConfigMetaData) added to ClusterConfigMetaData to merged the standardjboss.xml config into a partial jboss.xml config.
|
Good. I'll do it this way and get rid of defaults.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101995#4101995
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101995
18 years, 5 months
[Design of POJO Server] - Re: Leaking annotation API
by scott.stark＠jboss.org
"ALRubinger" wrote :
| @Clustered depends on org.jboss.ha.framework.interfaces.LoadBalancePolicy from trunk/cluster
|
This is also specific to a particular invocation implementation. This really can't be generically in ejb3 since its an aspect related to remoting. Its possible the server does not support anything but local ejbs, so ejb3 should not be providing this aspect.
"ALRubinger" wrote :
| @PoolClass has:
| Class<? extends Pool> value();
|
| ..where Pool defines:
|
| BeanContext<?> get();
|
| ..and BeanContext exposes many internals: Container, etc.
|
This is way too implementation specific for a client api. I would say you need to follow the factory approach suggested by Adrian where a client PoolFactory annotation provides the name of a registered Pool implementation. These would be registered with the factory in the ejb beans setup.
| @PoolFactory(type="EntityInstancePool",maxSize=10,timeout=300)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101987#4101987
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101987
18 years, 5 months
[Design of POJO Server] - Re: Issues with EJB2 ClusterConfigMetaData
by scott.stark＠jboss.org
"bstansberry(a)jboss.com" wrote :
| 1) Class exposes properties home(bean)LoadBalancingPolicy. DTD says they should be home(bean)LoadBalancePolicy (Balance not Balancing).
|
| That's a simple fix I've already made in my workspace; please advise if I should check it in; don't want to step on people.
|
fine, in the metdata project right?
"bstansberry(a)jboss.com" wrote :
| 2) The way ClusterConfigMetaData.determineHome(Bean)LoadBalancingPolicy() work, you only get the default policy if you added a cluster-config element to your bean declaration in jboss.xml. If the ClusterConfigMetaData came from a container-configuration, you *don't* get any default. You get null unless the value was specifically set in the relevant container-configuration/cluster-config element. This leads to test failures. A simple workaround to fix the test failures is to add the default policies to standardjboss.xml.
|
The default really should come from the container config. There still is too much logic in the ClusterConfigMetaData, and in fact I don't think we should be associating the ClusterConfigMetaData with a JBossEnterpriseBeanMetaData instance to figure out defaults based on bean type. We need a merge(ClusterConfigMetaData) added to ClusterConfigMetaData to merged the standardjboss.xml config into a partial jboss.xml config.
"bstansberry(a)jboss.com" wrote :
| 3) (I could be wrong about this; haven't tested, just looked at code. So, take this as more about how it should work). If you do something like this:
| ...
| Your bean will end up using RoundRobin instead of RandomRobin. AFAICT, the code checks the bean's config, and if not set goes to a hard coded default.
|
| Wouldn't it be better to pull the default from the container-configuration? If that's agreeable I can do that.
|
| 4) If yes to last question, that suggests there shouldn't be a hard coded default at all; the defaults should come from a container-configuration, ultimately from standardjboss.xml.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101973#4101973
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101973
18 years, 5 months
[Design of POJO Server] - Issues with EJB2 ClusterConfigMetaData
by bstansberry＠jboss.com
Been chasing down EJB2 clustering testsuite failures, which got me looking into handling of org.jboss.metadata.ejb.jboss.ClusterConfigMetaData. Found a few things:
1) Class exposes properties home(bean)LoadBalancingPolicy. DTD says they should be home(bean)LoadBalancePolicy (Balance not Balancing).
That's a simple fix I've already made in my workspace; please advise if I should check it in; don't want to step on people.
2) The way ClusterConfigMetaData.determineHome(Bean)LoadBalancingPolicy() work, you only get the default policy if you added a cluster-config element to your bean declaration in jboss.xml. If the ClusterConfigMetaData came from a container-configuration, you *don't* get any default. You get null unless the value was specifically set in the relevant container-configuration/cluster-config element. This leads to test failures. A simple workaround to fix the test failures is to add the default policies to standardjboss.xml.
3) (I could be wrong about this; haven't tested, just looked at code. So, take this as more about how it should work). If you do something like this:
In jboss.xml:
| <!-- A clustered SLSB -->
| <session>
| ... ...
| <clustered>true</clustered>
| <cluster-config>
| <partition-name>MyPartition</partition-name>
| </cluster-config>
| </session>
|
In standardjboss.xml:
| <container-configuration>
| <container-name>Clustered Stateless SessionBean</container-name>
| ... ...
| <cluster-config>
| <partition-name>${jboss.partition.name:DefaultPartition}</partition-name>
| <!-- Use RANDOM ROBIN!!! -->
| <home-load-balance-policy>
| org.jboss.ha.framework.interfaces.RandomRobin
| </home-load-balance-policy>
| <bean-load-balance-policy>
| org.jboss.ha.framework.interfaces.RoundRobin
| </bean-load-balance-policy>
| </cluster-config>
| </container-configuration>
|
Your bean will end up using RoundRobin instead of RandomRobin. AFAICT, the code checks the bean's config, and if not set goes to a hard coded default.
Wouldn't it be better to pull the default from the container-configuration? If that's agreeable I can do that.
4) If yes to last question, that suggests there shouldn't be a hard coded default at all; the defaults should come from a container-configuration, ultimately from standardjboss.xml.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101965#4101965
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101965
18 years, 5 months