Michael Jakl wrote: > Hi! > > On Mon, Aug 31, 2009 at 19:40, > bernd.fondermann<[email protected]> wrote: >> If you want to relay a message to many addressees (say thousands), we >> might not want to create 1000 lists, if we only want to replace the from >> entity for every new stanza and could reuse one list for that for every >> call of StanzaBuilder.createClone(). > > What about a method to create a mutable clone of the stanza, or if > each handler gets its own copy of a Stanza to mess around[1]? If we > had to relay the same message to thousands of users (pubsub), we could > simply set the "to" address and send it, for each of the users.
Because that either won't work or won't scale. Either we serialize the sending of 100 stanzas - this doesn't scale. Or we send out stanzas in parallel (like DeliveringInboundStanzaRelay _does_ currently on 10 threads or so) and then we cannot use one stanza or this will create unpredictable output. The copying actually is not so bad memory-wise. It only creates 1. a new top-level outer element (incl all objects created when an new element gets created) 2. another Array for Attributes 3. a new 'to' attribute 4. (maybe one or two more...) _but_ it re-uses all other attributes and inner elements. This of course only works if these sub-objects themselves are actually immutable. Look into StanzaBuilder.createClone() for more details. > > Granted, with delayed sending and queuing this might get problematic - > if we don't queue the character data to be send, but the object. But > then, there is no way to prevent thousands of objects to be created > anyways... . Why not? Immutable objects are the only way to prevent creating new objects e.g. to make 'by reference' behave cool. > > Anyway, it's good to see the functionality included, so +1 :) > > Michael > > 1: This could easily be optimized by creating the copy only if a > change to the object would be performed, which might not be the case > for most handlers. But that's a shot in the dark right now. How would this copy-on-write behavior effectively differ from what we have now? I think, there is no difference. Bernd
