RC2?

["Noel J. Bergman" <no...@devtech.com>]

Should we post up an RC2 with the dnsjava change?  I've already posted the
sar for private testing.  I can post it today, but I don't think we want to
ship without at least posting the candidate, do we?

Also, there is a reported NPE in Fetchmail for messages that do not have any
valid Sender or From headers.  Assuming that my analysis (on server-user@)
is correct, is it worth fixing that for the release, or go out with that
defect?

And I believe there is a memory leak under an error condition in the spooler
that I'll be fixing, but that should be able to wait for a 2.2.1.  If I am
correct, the nature of the error is here:

 if (lock(s)) {
     MailImpl mail = null;
     try {
        mail = retrieve(s);
     } catch (javax.mail.MessagingException e) {
       ...
     }
     if (mail == null) {
        continue;
     }

If there is a retrieve error, the lock is kept, and we leak.  Also ...

     if (filter.accept (mail.getName(),
                        mail.getState(),
                        mail.getLastUpdated().getTime(),
                        mail.getErrorMessage())) {
        return mail;
     }

If the filter doesn't accept, we leak the lock info, although we'll
eventually clean it up.  The problem here is that the message is forever
locked for this specific thread.  The patch is pretty simple (unlock the
message key).  The bug is in several places, although I should be able to
consolidate the code into one place.

I'm expecting that we'll hold off on the MDN code for this release, and am
only trying to clean up reported defects if they are serious.

	--- Noel


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

RE: RC2?

["Noel J. Bergman" <no...@devtech.com>]

> RC2 sounds good.

I am building, will do some testing, and post sometime this eveing if all
looks good locally.  Mind you, I don't test fetchmail, but the change I
applied looks reasonable:

 String from = "FETCHMAIL-SERVICE";
 try {
  from = ((InternetAddress)
getMessageIn().getFrom()[0]).getAddress().trim();
 }
 catch (Exception _) {
  getlogger.info("Could not identify sender -- using default value");
 }

The changes in the spooler is more textually complex, but should actually be
simpler code than we had.  And those will be tested on my system.

If I can, I'll tag just what I have, without the MDN code.  Otherwise, I'll
do a cvs up and tag it to include the MDN code, even though it will be
unused in this release.

	--- Noel


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

Re: RC2?

[Serge Knystautas <se...@lokitech.com>]

Noel J. Bergman wrote:
> Should we post up an RC2 with the dnsjava change?  I've already posted the
> sar for private testing.  I can post it today, but I don't think we want to
> ship without at least posting the candidate, do we?

RC2 sounds good.

> Also, there is a reported NPE in Fetchmail for messages that do not have any
> valid Sender or From headers.  Assuming that my analysis (on server-user@)
> is correct, is it worth fixing that for the release, or go out with that
> defect?

If we have a fix today, I'm fine with including it.

> And I believe there is a memory leak under an error condition in the spooler
> that I'll be fixing, but that should be able to wait for a 2.2.1.  If I am
> correct, the nature of the error is here:
> 
>  if (lock(s)) {
>      MailImpl mail = null;
>      try {
>         mail = retrieve(s);
>      } catch (javax.mail.MessagingException e) {
>        ...
>      }
>      if (mail == null) {
>         continue;
>      }
> 
> If there is a retrieve error, the lock is kept, and we leak.  Also ...
> 
>      if (filter.accept (mail.getName(),
>                         mail.getState(),
>                         mail.getLastUpdated().getTime(),
>                         mail.getErrorMessage())) {
>         return mail;
>      }
> 
> If the filter doesn't accept, we leak the lock info, although we'll
> eventually clean it up.  The problem here is that the message is forever
> locked for this specific thread.  The patch is pretty simple (unlock the
> message key).  The bug is in several places, although I should be able to
> consolidate the code into one place.

Similarly if we have a fix today, I would go for it in RC2.

> I'm expecting that we'll hold off on the MDN code for this release, and am
> only trying to clean up reported defects if they are serious.

You are reading my mind! :)

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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