mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: [vysper] cloning and forwarding stanzas
Date Tue, 01 Sep 2009 08:45:02 GMT
Michael Jakl wrote:
> Hi!
> On Mon, Aug 31, 2009 at 19:40,
> bernd.fondermann<bernd.fondermann@brainlounge.de> 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.


View raw message