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 09:27:39 GMT
Michael Jakl wrote:
> Hi!
> 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?

Ok, now I get it: you want to serialize early. Theoretically, that's an
optimization. However, in our case we just hand the stanza over to the
inbound session, where it get's checked and processed again, so we still
need the deserialized object.

>>> 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?

Yes. (Even more than 1000.)

> 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.

It's not 'easier'. It would use less objects, yet not neccessarily much
less memory though. Think about it: Queueing up the character data needs
much more memory: what's now stored as 1 immutable inner object (and
it's children) is then multiplexed into 1000s of character streams.
Probably this would need much more memory! (And don't tell me now to
store in special string objects what's unchanged, because this is what
we are doing now right now with immutable objects!)

>>>  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.

We could free the handler-developer from this 'burden' by introducing
copy-on-write semantics. However, this only hides what should not be
hidden: 'expensive' operations.
We also could move the broadcasting logic into it's own utitility.
However, I think it's pretty good how it is right now. The code is
reasonable lean and readable. We can still improve that in the future.


View raw message