Re: [Classpathx-javamail] Patch updating input streams and concurrency debugging

[chris burdess]

Doug Porter wrote:
> I've rewriten most of the input stream management in gnu.mail. Most of
> the replicated code is gone, replaced by classes for specific purposes
> that are combined as needed. I haven't changed all the MIME input streams
> yet because I don't have good test cases for them. The new code is much
> more reliable, based on tests here. And I'm confident that as we find
> bugs, it will be easier to fix them.
> 
> This also includes an updated version of simple concurrency debugging
> support. When debug messages are from different threads they print
> clearly. You can control whether to include timestamps and thread ids by
> setting properties.

i'll describe how this is supposed to work inline below.

> We now have a central Session.log to handle debug
> messages cleanly.

we can't do that - it changes the published javamail api.

> I've been working with a copy from cvs from a couple of weeks ago, so we
> may need to reconcile.

!!

> <   protected CRLFInputStream in;
> ---
> >   protected LineInputStream in;

could you explain why you want a LineInputStream? the CRLFInputStream
should provide us with the readLine method, which is all we need here.

> <       public int stat()
> ---
> >     public synchronized int stat()

no, we don't want to do this. the connection classes are unsynchronized.
whenever there is access to a connection, the caller synchronizes on the
connection object. this is necessary since some protocols may involve
a series of commands in a specified order - the connection will not be
in a usable state to any other caller in between such commands. it is
also more efficient.

as far as i am aware, wherever a service provider (Store, Folder, or
Message subclass) makes use of a connection, it synchronizes on the
connection. if it doesn't, that's a bug.

so no synchronized methods in *Connection classes.

> <               String cmd = new StringBuffer(LIST)
> <                       .append(' ')
> <                       .append(msgnum)
> <                       .toString();
> ---
> >             String cmd = LIST + " " + msgnum;

i'm not sure why you do this - perhaps for readability? it's actually
less efficient, since a new StringBuffer is created for each '+'. but
we're possibly splitting hairs.

> <       System.err.println("pop3: > "+command);
> ---
> >       Session.log ("POP> "+command);

while you could theoretically do this kind of thing at the moment, all
the connection classes and their support classes will shortly be
separated from the javamail project into a project of their own with no
dependency on javamail. so this wouldn't then be possible even if we
were allowed to modify the Session interface.

i will manage logging better by allowing a logger to be set.

> /usr/src/CVS/classpathx/mail/source/gnu/mail/providers/pop3/POP3Message.java
> /usr/src/tiger-0.5.2/thirdparty/classpathx-javamail-customized/mail/source/gnu/mail/providers/pop3/POP3Message.java
> <   extends ReadOnlyMessage 
> ---
> > //  extends ReadOnlyMessage 
> >   extends MimeMessage 

??

> <   void fetchContent() 
> ---
> >   synchronized void fetchContent() 

this already synchronizes on the connection.

> /usr/src/CVS/classpathx/mail/source/gnu/mail/util/CRLFInputStream.java
> /usr/src/tiger-0.5.2/thirdparty/classpathx-javamail-customized/mail/source/gnu/mail/util/CRLFInputStream.java
> 3c3
> <  * Copyright (C) 2002 The Free Software Foundation
> ---
> >  * Copyright (C) 2003 Doug Porter

you are joking, i hope.

> >  * This class should probably be deprecated. Too many other classes, such 
> > as 
> >  * LineInputStream and DotTerminatedInputStream, don't know whether this 
> > class wraps
> >  * their inner input streams. Those classes currently have to accomodate 
> > for lines
> >  * ending in both LF and CRLF.

no. the point of this class is that they don't. all you see this side if
a CRLFInputStream is LFs.

> <  * @author <a href="mailto:address@hidden";>Chris Burdess</a>
> ---
> >  * @author Doug Porter

!!

it's traditional to add your name to the list of authors when you update
code, rather than remove other people's...

in any case, there is absolutely nothing here that i am in any way
inclined to merge into gnu javamail, for all the reasons above. if you
can find bugs in the current (up-to-date) classes, that's a different
matter, let us know where and why.
-- 
chris burdess