james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Threads in James: Re: Tomcat + James in a single jvm process
Date Wed, 05 Jun 2002 13:52:38 GMT
Can you expand what you mean by *hack*?  JavaMail uses a socket factory, 
you specify a socket factory, you get SSL.  Sounds like a well designed 
approach.  I'm not sure what you were doing in your TLSRemoteDelivery 
mailet, but just by the name of it I'm wondering how/why you were 
determining whether a message should be sent via TLS.  That 
determination seems like the biggest issue, not the socket/delivery 
mechanism.

I haven't had time to review your recent submission as I keep working 
too late.  I'm hoping tonight I'll have some time.

Unfortunately I can't provide any more info about the problems with the 
Avalon thread pools.  What I have seen is James handling SMTP and POP3 
traffic, remotely delivering messages, but messages are just stuck in 
the spool.  Restart fixed it, and there were no log messages to explain 
what happened.  I've never had any luck debugging Avalon (resisting all 
temptations to rant :)
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com


Andrei Ivanov wrote:
> Hi, Serge
> 
> 
>>smtp).  You add 2 properties to the
>>javax.mail.Session properties, and
> 
> 
> No, this is not correct. This article is good example of how to *hack* java
> mail to make it SSL enabled but nothing more. I implemented one client (my
> first version of TLSRemoteDelivery) using this article, but alas this
> approach is not compatible with Avalon ideology at all.
> 
> 
>>from fine tuning from years of experience dealing with what other mail
> 
> I have to think about that, because, honestly, this is my deep concern as
> well. So far I am not ready to give answer for this your argument. But I
> still stay for my points from my previous email.
> 
> 
>>But ultimately, it's all about the code.  I'm happy to look over
>>whatever you would like to submit
> 
> 
> Did you have time to review my recent submission (SMTPServer-Handler)?
> 
> Andrei
> 
> PS could you please share more information about the problems you've
> experienced with excalibur threads. How I can repeat those? This is *very*
> critical for James based the solution I am working on.
> 
> 
> 
> ----- Original Message -----
> From: "Serge Knystautas" <sergek@lokitech.com>
> To: "James Developers List" <james-dev@jakarta.apache.org>
> Sent: Wednesday, June 05, 2002 4:08 PM
> Subject: Re: Threads in James: Re: Tomcat + James in a single jvm process
> 
> 
> 
>>Andrei Ivanov wrote:
>>
>>>Hi,
>>>I was about to offer this, just wanted so that initiative is not going
>>
> from
> 
>>>me :-)
>>>
>>>
>>>>We'd be pleased to accept your kind offer to contribute... ;-D
>>>>
>>>
>>>So I have RemoteDelivery mailet which doesn't use JavaMail for
>>
> transport,
> 
>>>which uses excalibur threads and cornerstone socket factory (and of
>>
> course
> 
>>>support TLS and so on). It works very well ;-D
>>>Unfortunately I implemented it before I got a chance to look at JavaMail
>>>sources which were released recently. Now I see some ways to improve it.
>>>
>>>Anyway before any further contributions from me I would like to hear
>>
> from
> 
>>>Serge about my improvements to SMTPServer-Handler submitted recently :-)
>>>
>>>Andrei
>>
>>Well, I'm not really enamored with refactoring working James code just
>>because Avalon provides functionality XYZ.  I can understand the
>>consistency argument.  However, I also have found the Avalon thread
>>pooler to be less reliable than the quick and dirty approach used by
>>RemoteDelivery (periodically I've had to restart James because the spool
>>manager threads had all died/hung while I haven't seen this with remote
>>delivery).
>>
>>I would like to remove the JavaMail delivery dependency because JavaMail
>>is not really a server-geared API.  That said, SMTP is an incredibly
>>challenging API not because of its complexity, but because it's been
>>around for so long and there are so many liberties other servers take
>>with it.  The settings that RemoteDelivery passes to the Transport are
>>from fine tuning from years of experience dealing with what other mail
>>servers can stand to hear.  Introducing a whole new codebase can be
>>extremely risky, because even if you can't deliver to 5% of the mail
>>servers out there, you're going to hear about it (but probably not until
>>a couple of weeks of bounces have been going on).
>>
>>As for SSL transport delivery, I think that's a reason to stick with
>>JavaMail actually... it's much more standard and well documented than
>>moving to a custom SMTP implementation and Avalon sockets.  Here's a
>>good article on the matter
>>
> 
> http://www.javaworld.com/javaworld/javatips/jw-javatip115.html?remote_addr=2
> 09.1.23.157&user_agent=Ultraseek/IDG.net
> 
>>(this talks about securing other providers, but the same should work for
>>smtp).  You add 2 properties to the javax.mail.Session properties, and
>>boom, you've got SMTP w/SSL.  Doesn't seem like we need to refactor there.
>>
>>But ultimately, it's all about the code.  I'm happy to look over
>>whatever you would like to submit, and I'll let you know what I think.
>>I just wanted to share some of my reservations going into this.
>>--
>>Serge Knystautas
>>Loki Technologies - Unstoppable Websites
>>http://www.lokitech.com


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message