[jira] Commented: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37841 ] Sridhar Komandur commented on AMQ-917: -- Hi, What is the status of applying the provided patch ? I have uploaded patch for the 4.1 code base (file name: dnc4.1lpatch.txt). Please let me know if I can help in expediting this. Thanks Regards - Sridhar Komandur > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector > Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: dnc4.1patch.txt, new_patchfile.txt, patchfile.txt, > patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sridhar Komandur updated AMQ-917: - Attachment: dnc4.1patch.txt > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector > Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: dnc4.1patch.txt, new_patchfile.txt, patchfile.txt, > patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ] Sridhar Komandur updated AMQ-917: - Attachment: new_patchfile.txt Please ignore the earlier attachment. > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector > Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: new_patchfile.txt, patchfile.txt, patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ] Sridhar Komandur updated AMQ-917: - Attachment: patchfile.txt per my earlier comment, patch to latest trunk. > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector > Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: patchfile.txt, patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (AMQ-917) Discovery Network Connector needs to clean up internal ...
[ https://issues.apache.org/activemq/browse/AMQ-917?page=all ] Sridhar Komandur reopened AMQ-917: -- I tested after apply the patch to the turnk (as of yesterday). It still breaks in a couple of places even without the patch (an example below). I will attach the new patchfile. > Discovery Network Connector needs to clean up internal ... > -- > > Key: AMQ-917 > URL: https://issues.apache.org/activemq/browse/AMQ-917 > Project: ActiveMQ > Issue Type: Bug > Components: Connector > Reporter: Sridhar Komandur > Assigned To: james strachan > Attachments: patchfile.txt > > > Consider the following scenario: All the brokers are using a directory > service based discovery agent (for example, DNS). Broker A comes up and tries > to connect to broker B, which is not functional yet. The Discovery Network > Connector at A adds service B to its tracking state "bridges" (list of > connected services) before activating the connection. However, if there is a > failure, the data structure is not cleaned up. When the DNS Discovery Agent > module rescans (DNS) and passes on uri for B into DNC, it simply ignores it > (as its tracking state hasn't been cleaned up upon prior failure). > The attached patch should take care of this issue (in the observed code path) > - test log below: > 2006-09-11 15:36:11,810 [main ] INFO > network.DemandForwardingBridge1 - Starting a network connection between > vm://localhost#0 and tcp://null:0 has been established. > 2006-09-11 15:36:48,158 [main ] DEBUG > network.DemandForwardingBridge1 - stopping localhost bridge to null is > disposed already ? false > 2006-09-11 15:36:48,158 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,159 [main ] INFO > ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: > localhost > 2006-09-11 15:36:48,162 [main ] INFO > vemq.broker.TransportConnector1 - Connector vm://localhost Stopped > 2006-09-11 15:36:48,162 [main ] DEBUG > network.DemandForwardingBridge1 - localhost bridge to null stopped > 2006-09-11 15:37:11,246 [main ] WARN > ivemq.network.NetworkConnector1 - Could not start network bridge between: > vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 > due to: java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-920) Two TCP connection requirement for bidirectional message flow ...
Two TCP connection requirement for bidirectional message flow ... - Key: AMQ-920 URL: https://issues.apache.org/activemq/browse/AMQ-920 Project: ActiveMQ Issue Type: Improvement Components: Connector Reporter: Sridhar Komandur We noticed the following during our testing When a broker A establishes connection to broker B, the message flow is unidirectional from A to B. This is a an issue for us: For example, consider brokers associated with business critical services X and Y. There are many secondary services that either monitor/feed off of the messages coming from them. A FOO service would like to process messages going from X to Y. So in FOO's broker configuration we add X's name. However, messages are not going to flow from X to FOO, till X initiates a connection to FOO. It may not be desirable/possible to change business critical brokers' configuration for usage scenarios like this. TCP is bidirectional and asymmetry at connection establishment should not be translated to the higher level network connector. Is there a fundamental need/justification for this design that I may not be aware of ? Otherwise I would like to explore other design options. Thanks Regards - Sridhar Komandur -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
MulticastDiscoveryAgent question ...
Team,
I had a question regarding the code below - doTimeKeepingServices() is
called the very first time and
then it is waiting on mcast.receive - so it will advertize itself after
hearing from another broker, assuming keepAliveInterval
has elapsed.
Should we instead run doTimeKeepingServices on its own schedule, instead of
relying on distributed event driven advertisement ? My concern is 1. that
since the first advertisement
is not retried, a new broker might miss others when its advertisement
(multicast packet) is lost on occasion (everybody is waiting on multicast
receive). 2. When large number of brokers are brought up, potential race
condition would result in some brokers not see each other.
I will create a Jira if somebody can confirm I haven't missed anything.
(Coming from a router background, usually there is a base timer that drives
all the calendar activity in the message router)
Thanks!
Regards
- Sridhar
public void run(){
byte[] buf=new byte[BUFF_SIZE];
DatagramPacket packet=new DatagramPacket(buf,0,buf.length);
while(started.get()){
doTimeKeepingServices();
try{
mcast.receive(packet);
if(packet.getLength()>0){
String str=new String(packet.getData(),packet.getOffset
(),packet.getLength());
processData(str);
}
}catch(SocketTimeoutException se){
// ignore
}catch(IOException e){
log.error("failed to process packet: "+e);
}
}
}
