> Despite the fact that most of the code is the same, I think > this change is too big for 1.7.x. Maybe it can be added to > cvs head and after a while (if people are willing to test it > in cvs-head) it can be backported. > > I'm also not sure whether it's a good idea for cvs-head, > because a lot of discussion lately is about > multicast/notification and whether a complete new pluggable > solution is needed. > Maybe we can add this to cvs-head for the time being and in > the near future start a project for making it more pluggable > and look into the whole event/notification structure in MMBase. > > I'm not sure whether the packagename must be something under > storage. I like org.mmbase.notification (without the storage).
I was afraid that this was going to happen when I proposed the hack. A lot of old and new ideas come up and blow up my simple hack request. If I add the spawning of threads back then my code does exactly the same as the old one. I then only switched two thread.run() methods. If I change line 235 and 241 in the MMBaseSharedStorage with "new MMBaseMultiCastProbe(this, bul, machine, id, tb, ctype, false);" then the thread spawning is restored. What I did with the old code: 1: I moved the MMBaseMultiCast.doWork() method to the MultiCastChangesReceiver and moved the MultiCastChangesReceiver.doWork() method to the MMBaseMultiCast. The thread from MultiCastChangesReceiver now reads the messages from the network and adds it to a queue and the MMBaseMultiCast does the notification to MMBase. This part of the code was a little confusing in the old one because the MultiCastChangesReceiver called a parent (MMBaseMultiCast) In my code this is replaced by local calls. 2: Changed the init method to get the properties from config/utils/multicast and modified MMBase.java to load a classname. 3: After step one I had two classes which did something with the network. The MMBaseMultiCast did not mention anything about sockets anymore. I extracted (cut&paste) the code which had nothing to do with multicast settings to a new class (MMBasSharedStorage). The leftovers in the MMBaseMultiCast class were only called on three places. I only had to implement those three methods to get an unicast implementation. Message http://www.mail-archive.com/[EMAIL PROTECTED]/msg04161.html is proposing a lot that was already there with some modifications. The old code isn't bad at all imo. The only thing that is bad is the fact that it calls the MMObjectBuilder.nodeLocalChanged() method. It should only have called MMObjectBuilder.nodeRemoteChanged() method, because it receives changes from a remote system. It is now abused for local changes. My hack is not about a change in event/notification in MMBase. It only streamlines the code for multicast and adds a unicast implementation. I hope people will look at the old and new code and compare then. Like I described above I can easily add the thread spwaning back. Old code: MMBaseChangeDummy.java MMBaseChangeInterface.java MMBaseMultiCast.java MMBaseMultiCastProbe.java MMBaseMultiCastWaitNode.java MultiCastChangesReceiver.java MultiCastChangesSender.java Nico ---------------------------------------------------------------------------- Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.--Charles Mingus
