Andr? van Toly <[EMAIL PROTECTED]> wrote: > At 13:16 +0200 20-04-2004, Michiel Meeuwissen wrote: > >There are more problems with multicast: > > > >- IIRC a multicast is not garanteed to be received > > That's true, multicast relies on UDP (like streams) in stead of TCP. > > >- multicast can only be done within the same subnet, while this is not true > > for the database connection. So, if you run 2 mmbase's on the same > > database, > > but in a different network, multicast cannot be used to synchronize the > > caches. > > OK, but creating something with for instance RMI > (TCP based) would need more resources...
Since multicast only happens at editing, peformance should not easily be a problem. I think that even if you set it up with one Thread it should easily be able to handle quite a lot of edits. And furthermore a delay of a few seconds does not matter, do it can simply queue if a 'burst' of invalidation requests comes in, and handle them one-by-one. > >So, perhaps there needs to be a small project who offers an alternative for > >multicast. Perhaps using RMI or so. It should then of course also consider > >this Thread issue. > If i remember reading correctly at irc this > afternoon is that more MMBase modules suffer from > this issue. Perhaps, but I would not know where excactly it could be problematic. I do btw think also that it is a bit silly that Threads are so expensive. The way to avoid the threads now, is writing your own code doing more or less the same, only in a specialized way (e.g. FileWatcher which now has only one static Thread, which basicly is a loop dividing the work to the FileWatchers instances, which sounds to me as a simply Thread simulation) Michiel -- Michiel Meeuwissen | Mediapark C101 Hilversum | +31 (0)35 6772979 | I hate computers nl_NL eo_XX en_US | mihxil' | [] () |
