[jboss-jira] [JBoss JIRA] (AS7-5598) It must be possible to define a cluster connection without static connectors or discovery-group
Jeff Mesnil (JIRA)
jira-events at lists.jboss.org
Fri Sep 21 10:18:35 EDT 2012
[ https://issues.jboss.org/browse/AS7-5598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720677#comment-12720677 ]
Jeff Mesnil edited comment on AS7-5598 at 9/21/12 10:18 AM:
------------------------------------------------------------
for reference, our IRC logs:
{noformat}
<fborges> AndyTaylor, Jeff was pointing out that our ClusterConnection class accepts null's for the discoveryGroup of the static connectors
AndyTaylor, is it the case, that we assume that IF the (other) connector is !null, we can allow these as null?
<AndyTaylor> fborges: can you point me at what you mean
<jmesnil> AndyTaylor, if both the discovery group and the static connectors are null, we instantiate a StaticClusterConnector with a null tcConfigs
AndyTaylor, imho, if the tcConfigs is null we should throw an exception. Otherwise we end up with a cluster connection with nothing to know the cluster
<AndyTaylor> jmesnil: don't we use this for one way connectors, in cluster rings etc
<jmesnil> AndyTaylor, ah good point
AndyTaylor, mmmh, if we define no static connectors, what does the cluster connection do?
<AndyTaylor> jmesnil: hmmm, yeah, maybe i am confusing it with something else
<jmesnil> AndyTaylor, I'll think about it but I think it's a bug to allow a cluster connection w/o a way to connect to the cluster :)
<AndyTaylor> jmesnil: let me check the examples. im sure there is one where we dont set either
<fborges> AndyTaylor, jmesnil fwiw, I am running all the unittests with a check forbidding null discoveryGroup or null staticConnectors
<AndyTaylor> fborges: jmesnil: see static-one-way example
fborges: jmesnil it works with allow-direct-connections-only so nodes can conenct to it but it cant connect to nodes
<AndyTaylor> fborges: + since we made the change that cluster connection size > 0 = clustered means we need to allow it
<jmesnil> AndyTaylor, you mean clustered-static-oneway?
<AndyTaylor> jmesnil: yes sorry
<jmesnil> AndyTaylor, in that case, it must still define a connector to be able to hop to the next node
<AndyTaylor> jmesnil: there is no next node, its at the end of the chain
<fborges> jmesnil, AndyTaylor it makes sense
jmesnil, AndyTaylor I will add some comments to ClusterConnection on it...
<jmesnil> AndyTaylor, fborges. Ok I understand that we must be able to create cluster connections without discovery group or static connectors
<jmesnil> AndyTaylor, fborges: I suppose this means we must also accept this for core bridges and JMS cf / pooled CF
<AndyTaylor> jmesnil: im not so sure about that
{noformat}
was (Author: jmesnil):
for reference, our IRC logs:
<fborges> AndyTaylor, Jeff was pointing out that our ClusterConnection class accepts null's for the discoveryGroup of the static connectors
AndyTaylor, is it the case, that we assume that IF the (other) connector is !null, we can allow these as null?
<AndyTaylor> fborges: can you point me at what you mean
<jmesnil> AndyTaylor, if both the discovery group and the static connectors are null, we instantiate a StaticClusterConnector with a null tcConfigs
AndyTaylor, imho, if the tcConfigs is null we should throw an exception. Otherwise we end up with a cluster connection with nothing to know the cluster
<AndyTaylor> jmesnil: don't we use this for one way connectors, in cluster rings etc
<jmesnil> AndyTaylor, ah good point
AndyTaylor, mmmh, if we define no static connectors, what does the cluster connection do?
<AndyTaylor> jmesnil: hmmm, yeah, maybe i am confusing it with something else
<jmesnil> AndyTaylor, I'll think about it but I think it's a bug to allow a cluster connection w/o a way to connect to the cluster :)
<AndyTaylor> jmesnil: let me check the examples. im sure there is one where we dont set either
<fborges> AndyTaylor, jmesnil fwiw, I am running all the unittests with a check forbidding null discoveryGroup or null staticConnectors
<AndyTaylor> fborges: jmesnil: see static-one-way example
fborges: jmesnil it works with allow-direct-connections-only so nodes can conenct to it but it cant connect to nodes
<AndyTaylor> fborges: + since we made the change that cluster connection size > 0 = clustered means we need to allow it
<jmesnil> AndyTaylor, you mean clustered-static-oneway?
<AndyTaylor> jmesnil: yes sorry
<jmesnil> AndyTaylor, in that case, it must still define a connector to be able to hop to the next node
<AndyTaylor> jmesnil: there is no next node, its at the end of the chain
<fborges> jmesnil, AndyTaylor it makes sense
jmesnil, AndyTaylor I will add some comments to ClusterConnection on it...
<jmesnil> AndyTaylor, fborges. Ok I understand that we must be able to create cluster connections without discovery group or static connectors
<jmesnil> AndyTaylor, fborges: I suppose this means we must also accept this for core bridges and JMS cf / pooled CF
<AndyTaylor> jmesnil: im not so sure about that
> It must be possible to define a cluster connection without static connectors or discovery-group
> -----------------------------------------------------------------------------------------------
>
> Key: AS7-5598
> URL: https://issues.jboss.org/browse/AS7-5598
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 7.2.0.Alpha1
>
>
> I constrained the messaging subsystem to not accept a cluster-connection without either a static-connectors or a discovery-group-name.
> However there is one use case where we must accept a cluster-connection without either: when a node must be part of a cluster, accepts connection but not attempts to connect to other nodes. This is shown by HornetQ clustered-static-oneway example where server3 accepts connections from server2 but does not connect to any other cluster nodes.
> The constraints must be relaxed to accept a cluster connection without a static connectors or a discovery-group-ref element
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list