[JBoss-dev] [JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12315958 ] B.S.Navin commented on JGRP-33: --- What does Channel.LOCAL do? I don't see any explanation in the java docs. JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 SUN JDK 1.5.0 on Windows Unix platforms Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Fix For: 2.2.8 Attachments: JGroupsMemTest.java, PublishThread2.java, fc-fast-udp-tcpping.xml, fc-fast-udp.xml, runj10.sh I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12315954 ] B.S.Navin commented on JGRP-33: --- But in many cases (and in this one too), there would be some members who just send messages to the group and are not concerned with receiving any of the messages. In such cases, the member would not call receive but will keep sending messages through the JChannel. Is there any other way for implementing such a case? JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 SUN JDK 1.5.0 on Windows Unix platforms Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Fix For: 2.2.8 Attachments: JGroupsMemTest.java, PublishThread2.java, fc-fast-udp-tcpping.xml, fc-fast-udp.xml, runj10.sh I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-31) Problem with MERGE2 when not using multicast
[ http://jira.jboss.com/jira/browse/JGRP-31?page=comments#action_12315645 ] B.S.Navin commented on JGRP-31: --- But a fix that would automatically make the merge (by either using the merge protocol or an additional protocol) looks more inline with the general JGroups trend. Doesn't it? Even if the solution results in a slight increase in the network traffic (either more packets or an additional header), it will be useful. Such a feature can be made configurable so that it can be enabled only where the additional network traffic is acceptable. Problem with MERGE2 when not using multicast Key: JGRP-31 URL: http://jira.jboss.com/jira/browse/JGRP-31 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN Java 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Fix For: 2.2.8 Hi, There is one case in which MERGE2 will fail while using TCPPING/UDP(without mcast): The initial_hosts property is abc.com[7800];xyz.com[7801]. These 2 machines are permanent group members (if they are up, they will be members of the group). Now there are numerous other programs on different machines that may dynamically join and leave the group. These members are not known before hand and cannot be specified in the initial_hosts property. The members on abc.com and xyz.com are started and they join the same group. Now another member from mnop.com starts and joins the group. The co-ordinator will be abc.com A network problem occurs and mnop.com is separated from abc.com and xyz.com mnop.com forms its own single-member group with itself as the co-ordinator. Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com periodically checks on the initial_hosts list to see if they are up. It now finds that abc.com is reachable and decides that abc.com is the leader (by lexical sorting) and will take care of the merging. So it does not go ahead with the merge. On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check if they can find members on the initial_hosts with a different co-ordinator. Both of them never consider mnop.com as it is not in the initial_hosts list So mnop.com will never be merged with the group. Even the new MERGE3 MERGEFAST protocols don't seem to help here. I checked them out and found the following: MERGEFAST works only if multicast is used, which is not my case. MERGE3 just sends I am co-ordinator messages to a null destination. So in the case where multicast is enabled, it goes to all possible members. But in my case, with multicast disabled, the message will only be unicast to each member of the current group. So in the above example, the I am co-ordinator messages will never go to mnop.com after the network problem. So even MERGE3 does not work in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-31) Problem with MERGE2 when not using multicast
[ http://jira.jboss.com/jira/browse/JGRP-31?page=comments#action_12315541 ] B.S.Navin commented on JGRP-31: --- Using a temp persistence store may not solve the issue. The issue would crop up if the network issue (or whatever caused the group to split) gets resolved after the idle time. Then, the store would no longer hold the isolated member details (mnop) and again the merge will never take place. Using TCPGOSSIP requires gossip routers. But there are many practical cases where it is not desirable to add one more component (gossip routers) to the system, but still use JGroups across subnets that restrict multicast (PING cannot be used). TCPPING fits perfectly in such cases except for this issue. :-( Problem with MERGE2 when not using multicast Key: JGRP-31 URL: http://jira.jboss.com/jira/browse/JGRP-31 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN Java 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Fix For: 2.2.8 Hi, There is one case in which MERGE2 will fail while using TCPPING/UDP(without mcast): The initial_hosts property is abc.com[7800];xyz.com[7801]. These 2 machines are permanent group members (if they are up, they will be members of the group). Now there are numerous other programs on different machines that may dynamically join and leave the group. These members are not known before hand and cannot be specified in the initial_hosts property. The members on abc.com and xyz.com are started and they join the same group. Now another member from mnop.com starts and joins the group. The co-ordinator will be abc.com A network problem occurs and mnop.com is separated from abc.com and xyz.com mnop.com forms its own single-member group with itself as the co-ordinator. Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com periodically checks on the initial_hosts list to see if they are up. It now finds that abc.com is reachable and decides that abc.com is the leader (by lexical sorting) and will take care of the merging. So it does not go ahead with the merge. On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check if they can find members on the initial_hosts with a different co-ordinator. Both of them never consider mnop.com as it is not in the initial_hosts list So mnop.com will never be merged with the group. Even the new MERGE3 MERGEFAST protocols don't seem to help here. I checked them out and found the following: MERGEFAST works only if multicast is used, which is not my case. MERGE3 just sends I am co-ordinator messages to a null destination. So in the case where multicast is enabled, it goes to all possible members. But in my case, with multicast disabled, the message will only be unicast to each member of the current group. So in the above example, the I am co-ordinator messages will never go to mnop.com after the network problem. So even MERGE3 does not work in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-40) Connections remain open even after the channel port changes, while using TCP
Connections remain open even after the channel port changes, while using TCP Key: JGRP-40 URL: http://jira.jboss.com/jira/browse/JGRP-40 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 Reporter: B.S.Navin Assigned to: Bela Ban I am using TCP/TCPPING as the base of the stack. Sometimes one of the members of the group gets shunned. That member then disconnects from the group and re-connects. This time, it gets assigned a different TCP port. But a netstat for ESTABLISHED connections shows the connections of the old and the new port still active. Shouldn't the connections for the old port have been closed? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-31) Problem with MERGE2 when not using multicast
[ http://jira.jboss.com/jira/browse/JGRP-31?page=comments#action_12315513 ] B.S.Navin commented on JGRP-31: --- One more possible solution (a more generic one) would be to create a small protocol that sits between TCPPING its underlying layer (UDP / TCP) that just adds an additional header to PING requests with the co-ordinator of this member. It can intercept any incoming PING requests and look for a different co-ordinator in the header pass a MERGE request up the stack. This protocol can be used only when using MERGE2/TCPPING/(UDP/TCP) with multicast disabled. Problem with MERGE2 when not using multicast Key: JGRP-31 URL: http://jira.jboss.com/jira/browse/JGRP-31 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN Java 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Fix For: 2.2.8 Hi, There is one case in which MERGE2 will fail while using TCPPING/UDP(without mcast): The initial_hosts property is abc.com[7800];xyz.com[7801]. These 2 machines are permanent group members (if they are up, they will be members of the group). Now there are numerous other programs on different machines that may dynamically join and leave the group. These members are not known before hand and cannot be specified in the initial_hosts property. The members on abc.com and xyz.com are started and they join the same group. Now another member from mnop.com starts and joins the group. The co-ordinator will be abc.com A network problem occurs and mnop.com is separated from abc.com and xyz.com mnop.com forms its own single-member group with itself as the co-ordinator. Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com periodically checks on the initial_hosts list to see if they are up. It now finds that abc.com is reachable and decides that abc.com is the leader (by lexical sorting) and will take care of the merging. So it does not go ahead with the merge. On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check if they can find members on the initial_hosts with a different co-ordinator. Both of them never consider mnop.com as it is not in the initial_hosts list So mnop.com will never be merged with the group. Even the new MERGE3 MERGEFAST protocols don't seem to help here. I checked them out and found the following: MERGEFAST works only if multicast is used, which is not my case. MERGE3 just sends I am co-ordinator messages to a null destination. So in the case where multicast is enabled, it goes to all possible members. But in my case, with multicast disabled, the message will only be unicast to each member of the current group. So in the above example, the I am co-ordinator messages will never go to mnop.com after the network problem. So even MERGE3 does not work in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=history ] B.S.Navin updated JGRP-33: -- Environment: SUN JDK 1.4.2_05 SUN JDK 1.5.0 on Windows Unix platforms (was: SUN JDK 1.4.2_05) Was able to reproduce the issue using SUN JDK 1.5.0 too JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 SUN JDK 1.5.0 on Windows Unix platforms Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Fix For: 2.2.8 Attachments: JGroupsMemTest.java, PublishThread2.java, fc-fast-udp-tcpping.xml, fc-fast-udp.xml, runj10.sh I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 Reporter: B.S.Navin Assigned to: Bela Ban Priority: Critical I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12315203 ] B.S.Navin commented on JGRP-33: --- Have tried reproduced this issue with the JGroups 2.2.7 release as well as the latest JGroups HEAD. JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=history ] B.S.Navin updated JGRP-33: -- Attachment: PublishThread2.java JGroupsMemTest.java runj10.sh The sample programs execution script for the reproducing the issue JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Attachments: JGroupsMemTest.java, PublishThread2.java, runj10.sh I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours
[ http://jira.jboss.com/jira/browse/JGRP-33?page=history ] B.S.Navin updated JGRP-33: -- Attachment: fc-fast-udp.xml fc-fast-udp-tcpping.xml Configuration files used for UDP/PING UDP/TCPPING JGroups throws OutOfMemoryError after running for a few hours - Key: JGRP-33 URL: http://jira.jboss.com/jira/browse/JGRP-33 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN JDK 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Attachments: JGroupsMemTest.java, PublishThread2.java, fc-fast-udp-tcpping.xml, fc-fast-udp.xml, runj10.sh I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. I have run the program on unix and windows machines with 1G RAM. Not able to make much from an HProf output of one of the instances. This seems to be the cause for the JBossCache bug http://jira.jboss.com/jira/browse/JBCACHE-31; too. I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-31) Problem with MERGE2 when not using multicast
Problem with MERGE2 when not using multicast Key: JGRP-31 URL: http://jira.jboss.com/jira/browse/JGRP-31 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN Java 1.4.2_05 Reporter: B.S.Navin Assigned to: Bela Ban Hi, There is one case in which MERGE2 will fail while using TCPPING/UDP(without mcast): The initial_hosts property is abc.com[7800];xyz.com[7801]. These 2 machines are permanent group members (if they are up, they will be members of the group). Now there are numerous other programs on different machines that may dynamically join and leave the group. These members are not known before hand and cannot be specified in the initial_hosts property. The members on abc.com and xyz.com are started and they join the same group. Now another member from mnop.com starts and joins the group. The co-ordinator will be abc.com A network problem occurs and mnop.com is separated from abc.com and xyz.com mnop.com forms its own single-member group with itself as the co-ordinator. Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com periodically checks on the initial_hosts list to see if they are up. It now finds that abc.com is reachable and decides that abc.com is the leader (by lexical sorting) and will take care of the merging. So it does not go ahead with the merge. On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check if they can find members on the initial_hosts with a different co-ordinator. Both of them never consider mnop.com as it is not in the initial_hosts list So mnop.com will never be merged with the group. Even the new MERGE3 MERGEFAST protocols don't seem to help here. I checked them out and found the following: MERGEFAST works only if multicast is used, which is not my case. MERGE3 just sends I am co-ordinator messages to a null destination. So in the case where multicast is enabled, it goes to all possible members. But in my case, with multicast disabled, the message will only be unicast to each member of the current group. So in the above example, the I am co-ordinator messages will never go to mnop.com after the network problem. So even MERGE3 does not work in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JGRP-31) Problem with MERGE2 when not using multicast
[ http://jira.jboss.com/jira/browse/JGRP-31?page=comments#action_12315095 ] B.S.Navin commented on JGRP-31: --- Possible solution: -- There is one possible solution I found to this: The merge() method in the org.jgroups.protocols.pbcast.CoordGmsImpl class sorts the coordinator list and decides who is the leader. We can add a property merge_leader to the pbcast.GMS protocol that defaults to false. This property means whether this member should assume itself as the merge leader or not. As it defaults to false, no existing configurations will be affected. Then in the merge() method of CoordGmsImpl, we can also check whether this property is true while deciding the leader. So if this property is true, it will itself become the merge leader. Then in cases like the one described in the example, all the members not in the initial_hosts list (the ones that join and leave the group dynamically unpredictably) can have their merge_leader property in pbcast.GMS set to true. I have tried it and it seems to work. Problem with MERGE2 when not using multicast Key: JGRP-31 URL: http://jira.jboss.com/jira/browse/JGRP-31 Project: JGroups Type: Bug Versions: 2.2.8 Environment: SUN Java 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Hi, There is one case in which MERGE2 will fail while using TCPPING/UDP(without mcast): The initial_hosts property is abc.com[7800];xyz.com[7801]. These 2 machines are permanent group members (if they are up, they will be members of the group). Now there are numerous other programs on different machines that may dynamically join and leave the group. These members are not known before hand and cannot be specified in the initial_hosts property. The members on abc.com and xyz.com are started and they join the same group. Now another member from mnop.com starts and joins the group. The co-ordinator will be abc.com A network problem occurs and mnop.com is separated from abc.com and xyz.com mnop.com forms its own single-member group with itself as the co-ordinator. Now suppose the network problem is fixed. The MERGE2 protocol on mnop.com periodically checks on the initial_hosts list to see if they are up. It now finds that abc.com is reachable and decides that abc.com is the leader (by lexical sorting) and will take care of the merging. So it does not go ahead with the merge. On the other hand, the MERGE2 protocol on both abc.com and xyz.com just check if they can find members on the initial_hosts with a different co-ordinator. Both of them never consider mnop.com as it is not in the initial_hosts list So mnop.com will never be merged with the group. Even the new MERGE3 MERGEFAST protocols don't seem to help here. I checked them out and found the following: MERGEFAST works only if multicast is used, which is not my case. MERGE3 just sends I am co-ordinator messages to a null destination. So in the case where multicast is enabled, it goes to all possible members. But in my case, with multicast disabled, the message will only be unicast to each member of the current group. So in the above example, the I am co-ordinator messages will never go to mnop.com after the network problem. So even MERGE3 does not work in this case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-31) Out of memory problem
[ http://jira.jboss.com/jira/browse/JBCACHE-31?page=comments#action_12314981 ] B.S.Navin commented on JBCACHE-31: -- Yes!!! SUN JDK 1.4.2_05. I am able to reproduce using this. Anyway, I'll also try on JDK 1.5. Out of memory problem - Key: JBCACHE-31 URL: http://jira.jboss.com/jira/browse/JBCACHE-31 Project: JBoss Cache Type: Bug Versions: 1.2 Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 1.2.1 Attachments: CacheMemTest.java Original Estimate: 1 week Remaining: 1 week I was able to reproduce the OOME using a simple java program using JBossCache. I have attached a java program CacheMemTest.java that mimicks our actual scenario (3 threads / process posting to the same JBossCache into the same node every time). I ran 5 instances of this program in different JVMs in the background. I passed numbers 1 to 5 as the arguments to the 5 programs (for the processNum). After about 3 hours, the program started throwing OOMEs.. The stack trace for each of them was : org.jboss.util.NestedRuntimeException: - nested throwable: (java.lang.OutOfMemoryError) at java.lang.Thread.run(Thread.java:552) Caused by: java.lang.OutOfMemoryError org.jboss.util.NestedRuntimeException: - nested throwable: (java.lang.OutOfMemoryError) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:3184) at org.jboss.cache.TreeCache.put(TreeCache.java:1741) at org.jboss.cache.TreeCache.put(TreeCache.java:1724) at CacheMemTest$PublishThread.run(CacheMemTest.java:65) Is this a known problem? Any idea how I can go about debugging this problem? Navin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-29) Messages are not sent to all members when using UDP with ip_mcast disabled
[ http://jira.jboss.com/jira/browse/JGRP-29?page=history ] B.S.Navin updated JGRP-29: -- Attachment: MessageTest.java A sample program to reproduce the problem. The argument to the program is the path to the config file Messages are not sent to all members when using UDP with ip_mcast disabled -- Key: JGRP-29 URL: http://jira.jboss.com/jira/browse/JGRP-29 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Sun JDK 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Attachments: MessageTest.java, fc-fast-udp.xml Original Estimate: 30 minutes Remaining: 30 minutes Attached the configuration file and the sample program. The stack is a TCPPING/UDP combination. UDP has ip_mcast diabled. So all messages will be unicast using UDP messages to each of the members. 2 members are started on ports 7800 and 7801 (7800 becomes the co-ordinator). When I send a message from 7801, the message does not go to 7800 at all. On checking the sources, I found that on sending, the UDP.sendUdpMessage() gets called from UDP.sendMultipleUdpMessages(). This method is called using the same Message object for each member of the group. In this case, sendMultipleUdpMessages sets the destination of the Message object to 7800 and calls sendUdpMessage. Here, the message is added to the outgoing packet handler queue. Then sendMultipleUdpMessages sets the destination of the Message object to 7801 and calls sendUdpMessage. But the Message object is the same. So actually the destination of the Message object in the queue gets changed to 7801 and the message is never delivered to 7800. A copy of the message should be added to the outgoing queue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-29) Messages are not sent to all members when using UDP with ip_mcast disabled
[ http://jira.jboss.com/jira/browse/JGRP-29?page=history ] B.S.Navin updated JGRP-29: -- Attachment: fc-fast-udp.xml The stack configuration used Messages are not sent to all members when using UDP with ip_mcast disabled -- Key: JGRP-29 URL: http://jira.jboss.com/jira/browse/JGRP-29 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Sun JDK 1.4.2_05 Reporter: B.S.Navin Assignee: Bela Ban Priority: Critical Attachments: fc-fast-udp.xml Original Estimate: 30 minutes Remaining: 30 minutes Attached the configuration file and the sample program. The stack is a TCPPING/UDP combination. UDP has ip_mcast diabled. So all messages will be unicast using UDP messages to each of the members. 2 members are started on ports 7800 and 7801 (7800 becomes the co-ordinator). When I send a message from 7801, the message does not go to 7800 at all. On checking the sources, I found that on sending, the UDP.sendUdpMessage() gets called from UDP.sendMultipleUdpMessages(). This method is called using the same Message object for each member of the group. In this case, sendMultipleUdpMessages sets the destination of the Message object to 7800 and calls sendUdpMessage. Here, the message is added to the outgoing packet handler queue. Then sendMultipleUdpMessages sets the destination of the Message object to 7801 and calls sendUdpMessage. But the Message object is the same. So actually the destination of the Message object in the queue gets changed to 7801 and the message is never delivered to 7800. A copy of the message should be added to the outgoing queue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-29) Messages are not sent to all members when using UDP with ip_mcast disabled
Messages are not sent to all members when using UDP with ip_mcast disabled -- Key: JGRP-29 URL: http://jira.jboss.com/jira/browse/JGRP-29 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Sun JDK 1.4.2_05 Reporter: B.S.Navin Assigned to: Bela Ban Priority: Critical Attached the configuration file and the sample program. The stack is a TCPPING/UDP combination. UDP has ip_mcast diabled. So all messages will be unicast using UDP messages to each of the members. 2 members are started on ports 7800 and 7801 (7800 becomes the co-ordinator). When I send a message from 7801, the message does not go to 7800 at all. On checking the sources, I found that on sending, the UDP.sendUdpMessage() gets called from UDP.sendMultipleUdpMessages(). This method is called using the same Message object for each member of the group. In this case, sendMultipleUdpMessages sets the destination of the Message object to 7800 and calls sendUdpMessage. Here, the message is added to the outgoing packet handler queue. Then sendMultipleUdpMessages sets the destination of the Message object to 7801 and calls sendUdpMessage. But the Message object is the same. So actually the destination of the Message object in the queue gets changed to 7801 and the message is never delivered to 7800. A copy of the message should be added to the outgoing queue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBCACHE-31) Out of memory problem
[ http://jira.jboss.com/jira/browse/JBCACHE-31?page=comments#action_12314938 ] B.S.Navin commented on JBCACHE-31: -- I was using JDK 1.4.2. I am able to reproduce on 1.4.2 Out of memory problem - Key: JBCACHE-31 URL: http://jira.jboss.com/jira/browse/JBCACHE-31 Project: JBoss Cache Type: Bug Versions: 1.2 Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 1.2.1 Attachments: CacheMemTest.java Original Estimate: 1 week Remaining: 1 week I was able to reproduce the OOME using a simple java program using JBossCache. I have attached a java program CacheMemTest.java that mimicks our actual scenario (3 threads / process posting to the same JBossCache into the same node every time). I ran 5 instances of this program in different JVMs in the background. I passed numbers 1 to 5 as the arguments to the 5 programs (for the processNum). After about 3 hours, the program started throwing OOMEs.. The stack trace for each of them was : org.jboss.util.NestedRuntimeException: - nested throwable: (java.lang.OutOfMemoryError) at java.lang.Thread.run(Thread.java:552) Caused by: java.lang.OutOfMemoryError org.jboss.util.NestedRuntimeException: - nested throwable: (java.lang.OutOfMemoryError) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:3184) at org.jboss.cache.TreeCache.put(TreeCache.java:1741) at org.jboss.cache.TreeCache.put(TreeCache.java:1724) at CacheMemTest$PublishThread.run(CacheMemTest.java:65) Is this a known problem? Any idea how I can go about debugging this problem? Navin -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JGRP-26) TCP/TCPPING creates too many unnecessary connections
TCP/TCPPING creates too many unnecessary connections Key: JGRP-26 URL: http://jira.jboss.com/jira/browse/JGRP-26 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Java 1.4.2 Reporter: B.S.Navin Assigned to: Bela Ban A simple program using JGroups with a TCP/TCPPING/FD combo at the bottom of the stack, creates too many unnecessary connections. The program just creates a channel and registers a message listener that just printss the message. When this program is run, it creates 2 TCP connections - One to the port of the TCP protocol of this program the other from the prot of the TCP protocol of this program. These 2 connections seem to be created when a ping message is sent to the hosts in the initial_hosts list of the TCPPING protocol. The target address should be checked and the message should automatically be processed within the same stack without sending it on the network, if the dest. address is same as this. Also, the FD protocol sends a message to its peer and receives a response. This causes 2 more connections to be created. Whereas the same connection could have been used to send the response message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-26) TCP/TCPPING creates too many unnecessary connections
[ http://jira.jboss.com/jira/browse/JGRP-26?page=history ] B.S.Navin updated JGRP-26: -- Attachment: fc-fast-tcp.xml Attaching the configuration file used. TCP/TCPPING creates too many unnecessary connections Key: JGRP-26 URL: http://jira.jboss.com/jira/browse/JGRP-26 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Java 1.4.2 Reporter: B.S.Navin Assignee: Bela Ban Attachments: fc-fast-tcp.xml A simple program using JGroups with a TCP/TCPPING/FD combo at the bottom of the stack, creates too many unnecessary connections. The program just creates a channel and registers a message listener that just printss the message. When this program is run, it creates 2 TCP connections - One to the port of the TCP protocol of this program the other from the prot of the TCP protocol of this program. These 2 connections seem to be created when a ping message is sent to the hosts in the initial_hosts list of the TCPPING protocol. The target address should be checked and the message should automatically be processed within the same stack without sending it on the network, if the dest. address is same as this. Also, the FD protocol sends a message to its peer and receives a response. This causes 2 more connections to be created. Whereas the same connection could have been used to send the response message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JGRP-26) TCP/TCPPING creates too many unnecessary connections
[ http://jira.jboss.com/jira/browse/JGRP-26?page=history ] B.S.Navin updated JGRP-26: -- Attachment: MessageTest.java Attached the sample program used too test this issue TCP/TCPPING creates too many unnecessary connections Key: JGRP-26 URL: http://jira.jboss.com/jira/browse/JGRP-26 Project: JGroups Type: Bug Versions: 2.2.8 Environment: Java 1.4.2 Reporter: B.S.Navin Assignee: Bela Ban Attachments: MessageTest.java, fc-fast-tcp.xml A simple program using JGroups with a TCP/TCPPING/FD combo at the bottom of the stack, creates too many unnecessary connections. The program just creates a channel and registers a message listener that just printss the message. When this program is run, it creates 2 TCP connections - One to the port of the TCP protocol of this program the other from the prot of the TCP protocol of this program. These 2 connections seem to be created when a ping message is sent to the hosts in the initial_hosts list of the TCPPING protocol. The target address should be checked and the message should automatically be processed within the same stack without sending it on the network, if the dest. address is same as this. Also, the FD protocol sends a message to its peer and receives a response. This causes 2 more connections to be created. Whereas the same connection could have been used to send the response message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
