[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why cloning messageUnit ?

Cyrille Giquello wrote: 
Hi,

a perhaps stupide question, but I really ask me it ...

Why there Cloning messageUnit before sending message ?

For exemple in :

in engine.ClientInfo.java.notifyAboutLogin()

           MessageUnitWrapper msgUnitWrapper = messageQueue.pull();
            if (msgUnitWrapper == null)
               break;
            MessageUnit msg = msgUnitWrapper.getMessageUnitClone();
            msg.qos = getUpdateQoS((String)null, msgUnitWrapper,
iMessage, numMessages);
            if (Log.TRACE) Log.trace(ME, "Flushing message #" + iMessage
+ ": " + msg.qos);
            MessageUnit[] arr = new MessageUnit[1];
            arr[0] = msg;
            // TODO: emails can also be sent to the logged off client!
            cbInfo.sendUpdate(this, msgUnitWrapper,arr);

If we're pulling the message from the queue, it is no more in the queue,
so why cloning it before sending ?

I needing to understand some background because I've planning to
"trying" to hack xmlBlaster and add a behavior : when PTP persistents
messages are sending to client, erasing them from file-system if they
were sending to the destination.


Hi Cyrille,

the messageUnit handle is a reference only, everybody who has
this handle can manipulate the content.

So if a new publish arrives, the new content would override the
old content in the queue, if it would be the same instance.

Another reason is that the callback plugin can't do any harm if
manipulating the messageUnit for example in the native plugin.

From a security aspect, the core classes should never have dangling
references around in the neighbours garden. Yes, even the most
trusted neighbour could misuse it.
In our case, I_XmlBlaster.java is the gateway into the xmlBlaster core,
no other entry point is existing.
So we can control security very simple.
As all the String arguments are immutable, there is no problem.
Only the publish has a week argument which we should change
in a future version as well.
A bad behaving protocol plugin driver could do funny things with this.

There are some other patterns in Java to address the readonly object problem.

In C++, there are even more possibilities to enforce readonly, the C++
"const" is much more usefull than the Java "final".

Probably we should switch forward to C++ again :-).

Marcel


--
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org