Re: Mail instance and multiple spool.store()

[Danny Angus <da...@apache.org>]

Stefano,
I think this may be a bug, I suspect that if anything else changed the
recipients between "store" and the actual write, that data would be
lost.
Given that mailets are multi threaded I suspect that this could
happen, resulting in mail being "lost" by some recipients and double
copies to others.

Hmm, I'll see if I can *make* it happen.

d.


On 5/31/05, Stefano Bagnara <ap...@bago.org> wrote:
> I see that RemoteDelivery does this:
>
> String name = mail.getName();
> for (Iterator i = targets.keySet().iterator(); i.hasNext(); ) {
>     String host = (String) i.next();
>     Collection rec = (Collection) targets.get(host);
>     if (isDebug) {
>         StringBuffer logMessageBuffer =
>             new StringBuffer(128)
>                     .append("Sending mail to ")
>                     .append(rec)
>                     .append(" on host ")
>                     .append(host);
>         log(logMessageBuffer.toString());
>     }
>     mail.setRecipients(rec);
>     StringBuffer nameBuffer =
>         new StringBuffer(128)
>                 .append(name)
>                 .append("-to-")
>                 .append(host);
>     mail.setName(nameBuffer.toString());
>     outgoing.store(mail);
> }
>
> Please note that at every iteration the same "mail" instance is changed and
> stored in the repository with a new name.
>
> Is this a supported way to handle Mailets Mail objects? Wouldn't be more
> correct to clone the original mail at each iteration, assigning the new name
> in the duplicate method and setting its recipients before storing it?
>
> Currently it works fine because RemoteDelivery does not support passthrough
> and because we use the setName that is not and should not be available via
> Mail interface.
>
> We should pay attention to this issues when talking about the new mailet
> API.
>
> Stefano
>
>

Re: Mail instance and multiple spool.store()

[Stefano Bagnara <ap...@bago.org>]

Danny Angus ha scritto:
> Stefano,
> I think this may be a bug, I suspect that if anything else changed the
> recipients between "store" and the actual write, that data would be
> lost.
> Given that mailets are multi threaded I suspect that this could
> happen, resulting in mail being "lost" by some recipients and double
> copies to others.

I don't think it may happens: mailets are multi threaded but a single
mail is processed by a single mailet at each time. Mail objects are
never accessed by multiple threads concurrently.

Stefano

> Hmm, I'll see if I can *make* it happen.
> 
> d.
> 
> 
> On 5/31/05, Stefano Bagnara <ap...@bago.org> wrote:
>> I see that RemoteDelivery does this:
>>
>> String name = mail.getName();
>> for (Iterator i = targets.keySet().iterator(); i.hasNext(); ) {
>>     String host = (String) i.next();
>>     Collection rec = (Collection) targets.get(host);
>>     if (isDebug) {
>>         StringBuffer logMessageBuffer =
>>             new StringBuffer(128)
>>                     .append("Sending mail to ")
>>                     .append(rec)
>>                     .append(" on host ")
>>                     .append(host);
>>         log(logMessageBuffer.toString());
>>     }
>>     mail.setRecipients(rec);
>>     StringBuffer nameBuffer =
>>         new StringBuffer(128)
>>                 .append(name)
>>                 .append("-to-")
>>                 .append(host);
>>     mail.setName(nameBuffer.toString());
>>     outgoing.store(mail);
>> }
>>
>> Please note that at every iteration the same "mail" instance is changed and
>> stored in the repository with a new name.
>>
>> Is this a supported way to handle Mailets Mail objects? Wouldn't be more
>> correct to clone the original mail at each iteration, assigning the new name
>> in the duplicate method and setting its recipients before storing it?
>>
>> Currently it works fine because RemoteDelivery does not support passthrough
>> and because we use the setName that is not and should not be available via
>> Mail interface.
>>
>> We should pay attention to this issues when talking about the new mailet
>> API.
>>
>> Stefano
>>
>>
>