Hi! On Tue, Sep 1, 2009 at 10:45, Bernd Fondermann<[email protected]> wrote: > Michael Jakl wrote: >> 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.
How could it produce unpredictable output if we queue the character data instead of the stanza object? That is what I wanted to articulate with the next paragraph, if we queue character data (stanzas as strings which are immutable per definition), I see nothing to prevent this from working neither serial nor parallel? >> 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. The immutable object doesn't help when I want to change the to address and send it to 1000 recipients, I do have to create 1000 new objects with a single attribute changed, don't I? Of course your cloning is done very clever and doesn't require twice the memory for two copies. I just thought it would be easier to queue the character data that should be send instead of the stanza-object itself, but there might be no need for this. >> 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. The idea was to free the handler-developer of the burden to decide to copy the stanza or not, on a second thought this might not work as I thought. This was a miserable side-remark I shouldn't have included. Michael
