mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Jakl <jakl.mich...@gmail.com>
Subject Re: [vysper] cloning and forwarding stanzas
Date Tue, 01 Sep 2009 09:07:24 GMT

On Tue, Sep 1, 2009 at 10:45, Bernd Fondermann<bf_jak@brainlounge.de> wrote:
> Michael Jakl wrote:
>> 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.

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.


View raw message