Robert Burrell Donkin (JIRA) ha scritto:
[ https://issues.apache.org/jira/browse/JAMES-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619309#action_12619309 ]
Robert Burrell Donkin commented on JAMES-850:
---------------------------------------------
Agreed
I wonder whether we might be able to simply the implementation by using
poor-man's-clone only for attributes rather than the complete hash map. Maybe
I'll try find to give it a while locally.
if (mail instanceof MailImpl) {
setAttributesRaw((HashMap) cloneSerializableObject(((MailImpl)
mail).getAttributesRaw()));
} else {
HashMap attribs = new HashMap();
for (Iterator i = mail.getAttributeNames(); i.hasNext(); ) {
String hashKey = (String) i.next();
attribs.put(hashKey,cloneSerializableObject(mail.getAttribute(hashKey)));
}
setAttributesRaw(attribs);
}
The cloneSerializableObject of the full hashmap is an optimization to
avoid running cloneSerializableObject on each attribute.
Anyway we may have nested HashMaps as an attribute value, so *IF* the
issue is the way we clone HashMaps then we'll have to deal with it
anyway because we didn't restrict what can be stored in a mailet
attribute (we just tell it must be serializable).
I have no idea why this code does not work as we expect:
private static Object cloneSerializableObject(Object o) throws
IOException, ClassNotFoundException {
ByteArrayOutputStream b = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(b);
out.writeObject(o);
out.flush();
out.close();
ByteArrayInputStream bi=new ByteArrayInputStream(b.toByteArray());
ObjectInputStream in = new ObjectInputStream(bi);
Object no = in.readObject();
return no;
}
Maybe we are hitting a weird java bug (a lot weird because we have this
with many different JVM and on different platforms)...
It shouldn't be a synchronization issue because have a single remote
delivery thread there, dealing with one spool repository.
One major change I've wanted to propose for a while is a move to a
data+meta-data message paradigm. The idea is that the incoming message would
not be constantly transformed during passage, rather the message would be
stored and any processing done only at the meta-data level. Only on exgress
would changes be consolidated. This would help to reduce copying of the
message content as well as offers potential simplifications of the architecture.
I (and I think all of the PMC) agree on this split of the Message and
the "Envelope" where the Envelope is both the "SMTP specific envelope"
(FROM/HELO/TO/AUTH...) and the Mailet processing data (mailet
attributes, mail "state", last updated..).
If you remember I linked to a thread I discussed with James Strachan
about using JCR for the incoming MimeMessages and JMS for the spooling
of the envelope.
About this, I also often thought we would need an analisys to understand
if it worth having also the mimemessage header as part of the envelope,
so that simple changes to the header would not require read/write/clone
of the messagebody, but this would make the paradigm more complicate and
I'm not sure if the performance worth this increased complexity.
In this specific case the issue is the clone of the attributes, so if
we'd keep dealing with this the same way we'll have this issue anyway.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
