-
15. Re: Separate netty connections for producer and consumer?
Ok, is there a bug in paging you have found, I havent been following that thread?
We still have no option to come out of paging mode unless to stop the producers temporarily (what is no option in a production system).
so you cant use blocking then? wont stopping the acceptors stop the producers anyway?
-
16. Re: Separate netty connections for producer and consumer?
Andy Taylor wrote:
so you cant use blocking then? wont stopping the acceptors stop the producers anyway?
No we want to use paging in any case.
By stopping the acceptor the client gets a timeout and will fail over to another node in the cluster (similiar to shutting down the node).
-
17. Re: Separate netty connections for producer and consumer?
By stopping the acceptor the client gets a timeout and will fail over to another node in the cluster (similiar to shutting down the node).
ok then HornetQServerControl:closeConnectionsForAddress should do the same thing
-
18. Re: Separate netty connections for producer and consumer?
Andy Taylor wrote:
ok then HornetQServerControl:closeConnectionsForAddress should do the same thing
Sure but this would stop producers AND consumers. We only want to stop the producers.
-
19. Re: Separate netty connections for producer and consumer?
Sure but this would stop producers AND consumers. We only want to stop the producers.
ok, so they are on the same IP address?
-
20. Re: Separate netty connections for producer and consumer?
Andy Taylor wrote:
ok, so they are on the same IP address?
Yes, this would be the normal case!
-
21. Re: Separate netty connections for producer and consumer?
I am pretty sure that the this acceptor definition would work. What I am seeing is that the first connection is established to the correct port but subsequent connections go to the port where the connector of the <cluster-connection> is listening. When I disable the <cluster-connection> server-side it works as expected (besides that client-side load balancing is of course not anymore working without the clustering). So my assumption is that the clients gets the stub in which the wrong connector configuration is delivered. I have seen in the code that an acceptor is always equipped with a cluster-connection. No idea how one can prevent this behavior without completely removing the clustering.
-
22. Re: Separate netty connections for producer and consumer?
I am pretty sure that the this acceptor definition would work. What I am seeing is that the first connection is established to the correct port but subsequent connections go to the port where the connector of the <cluster-connection> is listening. When I disable the <cluster-connection> server-side it works as expected (besides that client-side load balancing is of course not anymore working without the clustering). So my assumption is that the clients gets the stub in which the wrong connector configuration is delivered. I have seen in the code that an acceptor is always equipped with a cluster-connection. No idea how one can prevent this behavior without completely removing the clustering.
ahhhh, you have a cluster defined. yes thats the behavior i would expect. after a client initially connects to the cluster it receives the list of available connections from the cluster connections and uses these.
-
23. Re: Separate netty connections for producer and consumer?
Andy Taylor wrote:
ahhhh, you have a cluster defined. yes thats the behavior i would expect. after a client initially connects to the cluster it receives the list of available connections from the cluster connections and uses these.
Yes it is a cluster:
<cluster-connections>
<cluster-connection name="eap6-cluster">
<address>eap6.cluster</address>
<connector-ref>netty-internal-connector</connector-ref>
<use-duplicate-detection>true</use-duplicate-detection>
<forward-when-no-consumers>true</forward-when-no-consumers>
<discovery-group-ref discovery-group-name="dg-group1"/>
</cluster-connection>
</cluster-connections>
The "connector-ref" refers to the netty acceptor with the port 11832 (which is delivered to the clients after the initial connect). My assumption was that the cluster connection is only used for the communication of the nodes server-side. Why is it used for the clients? Any chance to change this?