james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jira] Commented: (JAMES-850) RemoteDeliveryTest intermitant failure
Date Sun, 03 Aug 2008 11:41:03 GMT
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

if (mail instanceof MailImpl) {
setAttributesRaw((HashMap) cloneSerializableObject(((MailImpl) 
} else {
HashMap attribs = new HashMap();
for (Iterator i = mail.getAttributeNames(); i.hasNext(); ) {
     String hashKey = (String) i.next();

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


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message