Subject: NPE in FD_SOCK.interruptPingerThread - msg#00091

Previous Message by Date: click to view message preview

RE: Looking for guidance....

Going back and reviewing your problem description, I think my problem is exactly what you are seeing.  I implemented your fix (below) in UNICAST, rebuilt the JGroups .JAR file, and we are now testing.  At this time it appears that the problem has NOT been resolved.  We are trying to capture another debug trace to verify the code, but right now it appears that this fix doesn’t help.  I’ll post again when I have more info.   Jerry Jalenak Software Engineer Netopia, Inc. From: javagroups-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:javagroups-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of matthias.weber@xxxxxxxxxxx Sent: Tuesday, May 23, 2006 3:09 AM To: javagroups-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [javagroups-users] Looking for guidance....   Seems to be the same bug in UNICAST I ran into a few days ago? You can try to fix it with following workaround (works for me): org.jgroups.protocols.UNICAST.java: case Event.VIEW_CHANGE : // remove connections to peers that are not members anymore !         Vector new_members = ((View)evt.getArg()).getMembers();         Vector left_members;         synchronized (members) {                 left_members = Util.determineLeftMembers(members, new_members);                 members.clear();                 if (new_members != null)                         members.addAll(new_members);         }         // Remove all connections for members that left between the current view and the new view         // See DESIGN for details         boolean rc;         if (use_gms && left_members.size() > 0) {                 Object mbr;                 for (int i = 0; i < left_members.size(); i++) {                         mbr = left_members.elementAt(i);                         rc = removeConnection(mbr);                         if (rc && trace)                                 log.trace("removed " + mbr + " from connection table, member(s) " + left_members                                         + " left");                 }         }         // --------------------------------- Start insertion -----------------------------------         for (Iterator it = previous_members.getContents().iterator(); it.hasNext();) {                 Object mbr = it.next();                 if (members.contains(mbr)) {                         if (previous_members.removeElement(mbr) != null && trace)                                 log.trace("removing " + mbr                                         + " from previous_members as result of VIEW_CHANGE event, previous_members="                                         + previous_members);                 }         }         // ---------------------------------- Insertion end  ---------------------------------         break; Regards, Matthias Weber Gesendet von:        javagroups-users-admin@xxxxxxxxxxxxxxxxxxxxx An:        "Bela Ban" <belaban@xxxxxxxxx> Kopie:        <javagroups-users@xxxxxxxxxxxxxxxxxxxxx> Thema:        RE: [javagroups-users] Looking for guidance.... [Virenprüfung durchgeführt] Not that I can tell. IPMP doesn't appear to be turned on on these boxes. We have also been doing some additional application configuration testing this morning.  Here is what we have found out: 2 Solaris 9 servers, connected via a hub. Each servers hosts 2 instances of our web application. To test these, we pull the network cable from server1 for 1 minute, then plug it back in.  We then attempt to run a command from server1 that sends a command (multicast) to the server2.  Here are our findings - Server1              Server2                   Result 1 App instance       1 App instances           PASS - Everything works! Server1              Server2                   Result 1 App instance       2 App instances           FAILS Server1              Server2                   Result 2 App instances      1 App instance            PASS Server1              Server2                   Result 2 App instances      2 App instances           FAILS In the third test case, if we run a command now from server2 to server1, it fails. In the logs we can see where the cluster is initially created, where the sub-clusters are created when the cable is pulled, and the MERGEVIEWs (i.e. a UNICAST operation) occurring when the cable is plugged back in. But it appears that, if there are two instances of JGROUPS on a single server, even though the cluster is re-merged correctly, MULTICASTing doesn't work anymore.  I've trapped through the code (intend to do more today) and I can see where the command is being sent by server1 and (I think) received by server2.  But I don't think the response is being returned correctly, and I suspect that it has to do with the second instance of JGROUPS on server2 - but I don't know why that would affect anything. I *really* need some help on figuring this one out.  Thanks in advance..... Jerry Jalenak Software Engineer Netopia, Inc. -----Original Message----- From: Bela Ban [mailto:belaban@xxxxxxxxx] Sent: Friday, May 19, 2006 3:35 PM To: Jalenak, Jerry Cc: javagroups-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [javagroups-users] Looking for guidance.... Do you use IP Multipathing (*not* Multicasting) on Solaris ? JGroups doesn't work with IP Multipathing on Solaris. Check whether this is enabled, check for logical interfaces, e.g. hme0:1, qfe2:1 etc Jalenak, Jerry wrote: > > All, > > We have a two server cluster running Solaris 9. Each server has two > instances of our application on it. Each server is also connected to a > switch which sits behind a load balancer (this is a web application). > We use JGroups with the default-minmalthreads protocol stack to handle > the unicast / multicast traffic between the four instances. Everything > work great until we pull the network cable. I can see JGroups split > into two sub-groups, and then when the cable is plugged back in, see > the groups re-join. The problem is, our application stops responding. > And here's another kicker - we have a Linux cluster that mirrors the > Solaris configuration. When we pull the cable on this cluster and plug > it back in, everything merges and continues to run without any issues > (application responds, etc.) I don't think this is a JGroups issue, > but I'm hoping someone out there has more experience with Solaris than > I do and can maybe tell me that Solaris has a problem with network > interruptions...... > > Any help, pointers, links to documented issues, etc. would be > **greatly** appreciated.... > > Thanks in advance. > > /*/Jerry Jalenak/*/ > > //Software Engineer// > > //Netopia, Inc.// > -- Bela Ban Lead JGroups / Manager JBoss Clustering Group callto://belaban ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ javagroups-users mailing list javagroups-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/javagroups-users

Next Message by Date: click to view message preview

Re: Multiple states, Last value cache

Well, I see the hashmap as your state, and the messages with the quotes (byte[]) as your state modifications (I assume they end up modifying the hashmap). So joining members will get the hashmap, and from then on keep in sync with everybody else via messages. Badrinarayanan Doraiswamy wrote: Hi, Clarifying point 3 and 4 in mail below: Qn 3) Is it possible to maintain multiple states? My application publishes financial info to clients. When the server starts, it publishes data for many currencies (USD.EUR, USD.JPY, etc) which are stored in a HashMap as key, value pairs. this HashMap is sent in the channel.send(hashmap); There is an engine which feeds my program the data to be sent to clients. This engine will feed incremental data after the first instance as byte[]. For ex: Byte[] containing : USD.EUR $1.000/1.111 (EUR), Bid Qty:1000, Ask Qty:2000. (This data is just a changed subset of the entire data). Lets say at this moment, a member joins a group, a FLUSH must happen, he must get the HashMap's state & use it for his display purposes rather than just getting the byte[]. There might be instances when the engine might provide HashMap & byte[] alternately in random order. My question is, is it then possible to maintain 2 objects state HashMap & byte[] & when a new member joins a group, he obtains the HashMap with all values & the old members just receive the incremental byte[]. Qn 4) Can I know if it is possible to maintain the Last value cache using JGroups? This question is almost same as Qn 3. Last value cache actually means caching the state of the last object (in my case caching the HashMap) & when a member joins, he must receive a HashMap rather than byte[]. Thanks for your time & help. Regards D.Badrinarayanan --- Bela Ban <belaban@xxxxxxxxx> wrote: Badrinarayanan Doraiswamy wrote: Hi, I have 4 questions to the group: Question 1: I have 3 processes Co-ordinator A1, 2 members B1, C1. All 3 belong to the same group & B1, C1 are receiving messages sent by co-ordinator A1. Network went down & co-ordinator A1 disconnected & re-connected to the same group. A1 sends messages, but members B1 & C1 do not receive messages sent by A1. In my application A1 is the only person sending messages. 1) How to configure clients B1, C1 to receive messages? Is it possible? This was discussed today on the list (Matthias Weber), checkout the latest copy of JGroups from CVS and retry. This should work. I also added some properties, with which I tested this on my home network (pulling the ethernet plug, pulling the power on the switch etc, and it worked fine): pulltheplug.xml in ./conf. Qn 2) I saw a post on sourceforge which mentioned UDP_NIO might be deprecated & removed in the future releases. What about tcp_nio? Yes, UDP_NIO has been moved to obsolete. TCP_NIO is supported, in fact it is the recommended solution (over org.jgroups.protocols.TCP) if you have to use TCP rather than IP multicasting Qn 3) Is it possible to maintain multiple states? For ex, in my application, there are instances when the server will be sending eihter a HashMap of data at one instance or a byte[] (which is just a small delta change in data)? When a new member joins the group, he must be able to receive the full data which is in the HashMap, use it for displaying all the data on his screen. There could be a possibility that the last state sent by the server could be a byte[] before he joined. Is there a possibility? I don't have a clue what you mean... Qn 4) Can I know if it is possible to maintain the Last value cache using JGroups? I saw articles which mention OSCache, JBoss Cache, etc can be used in conjunction with JGroups to maintain the last value cache. I would appreciate if anyone can give me some insights about this. What's a Last Value Cache ? -- Bela Ban Lead JGroups / Manager JBoss Clustering Group callto://belaban __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Bela Ban Lead JGroups / Manager JBoss Clustering Group callto://belaban ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642

Previous Message by Thread: click to view message preview

[jgroups-dev] [Fwd: SourceForge.net mailing list service upgrade (Mailman)]

FYI -------- Original Message -------- Subject: SourceForge.net mailing list service upgrade (Mailman) Date: Tue, 23 May 2006 05:52:43 -0700 (PDT) From: SourceForge.net Team <noreply@xxxxxxxxxxxxxxx> To: belaban@xxxxxxxxx Greetings, You are receiving this mail because you are listed as an administrator of a SourceForge.net project that has active mailing lists. As a continued measure to improve our service offering, we are migrating all existing mailing lists to Mailman 2.1.8 (latest stable release). This is the first major upgrade to the Mailman software used for mailing list service in more than four years. We expect this upgrade to both improve security and performance, and to provide a number of features not available in our existing Mailman service offering. We have been testing the new mailing list infrastructure for several weeks with the assistance of a few select projects. Our general migration of all mailing lists to this new infrastructure will begin 2006-05-23. Migration is being handled in several one-day segments and minimal downtime for list service is expected. Before the migration begins in earnest, we wanted to provide you this notice of some specific service changes: 1. Our new Mailman install will no longer permit the editing of HTML page templates and existing customizations to these templates will not be migrated. We made this decision to ensure consistency of the UI among all projects, allow future upgrades without worry about the compatibility of customized templates, eliminate issues related to broken or corrupt templates. In lieu of template modification, we encourage projects to provide list details and instructions via the "introductory description" list configuration option. This option supports basic HTML, so should be powerful enough for conveying intended information, while adhering to common look and feel. 2. List archival is implicitly enabled. It is not possible to opt-out of mailing list archival. As per our Mailing List site documentation (http://sf.net/docman/display_doc.php?docid=12983&group_id=1#mlarchives), list archival is mandatory. In reviewing data to be migrated, we have discovered a small number of older lists which had archiving turned off. The ability to disable archival is no longer supported, and archives will be maintained for all lists. If you currently run lists without archival, we encourage you to revisit the perceived need for unarchived lists (for example, we have found unarchived lists that were used for the distribution of centralized team passwords, and upon review by the project, it was clear that this was a practice which should be changed). Control over access to your mailing list archives is established on a per-list basis from the mailing list administration page for your project on the SourceForge.net site. Lists in a 'deleted' status will not have web-visible archives. Individual mailing list posts may be excluded from view by project administrators from the mailing list archive pages. Additional details on data visibility may be found at: http://sf.net/docs/G03#mailing_lists Questions or concerns regarding the mailing list service upgrade may be raised at: https://sourceforge.net/tracker/?func=add&group_id=1&atid=200001 Thank you, The SourceForge.net team . -- Bela Ban Lead JGroups / Manager JBoss Clustering Group callto://belaban ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Javagroups-development mailing list

Next Message by Thread: click to view message preview

Re: NPE in FD_SOCK.interruptPingerThread

Created http://jira.jboss.com/jira/browse/JGRP-239. But I'm not sure I want to fix this in 2.3, I want to release a CR tomorrow, and then go final with 2.3 in 2 weeks. I'll push this into 2.4, since it doesn't occur very frequently. Okay ? Bruce Schuchardt wrote: I doubt that I could reproduce it, but one of our apps ran into a NPE in FD_SOCK.interruptPingerThread on this line if(pinger_thread != null && pinger_thread.isAlive()) { This was during the passing down of a new view from pbcast.GMS.installView. It looks like some synchronization is needed for this check in a few places in FD_SOCK. -- Bela Ban Lead JGroups / Manager JBoss Clustering Group callto://belaban ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642