You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Andrei Ivanov <my...@surfeu.fi> on 2002/06/05 11:29:12 UTC
Threads in James: Re: Tomcat + James in a single jvm process
Hi,
just a side note.
> In James' case you would either use phonenix to host another service, or
you
> could use Mailets to start new threads.
When I came across with this phrase. Do you mean same way as threads
created in RemoteDelivery? I don't think this is a right way. My opinion is
that RemoteDelivery needs to be refactored asap. It shall use
Phoenix-Excalibur threads and it shall not use JavaMail for SMTP transport
(cornerstone socket factory shall be used instead)
Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Serge Knystautas <se...@lokitech.com>.
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" <se...@lokitech.com>
> To: "James Developers List" <ja...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Andrei Ivanov <my...@surfeu.fi>.
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" <se...@lokitech.com>
To: "James Developers List" <ja...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Danny Angus <da...@apache.org>.
> 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.
Thats a good point, and one thats reflected in the number of tiny but
significant bugs in both James and JavaMail (not just the SMTP bits).
There are so many idiosyncracies which have crept into the standards and
common practices that it is difficult to handle every "boundary condition"
satisfactorily, it is my opinion that we don't duplicate work done by Sun
wherever possible.
That said I also think that we could improve performance of remote delivery
by batching up mail to be delivered to a single host and delivering it in a
single session.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Serge Knystautas <se...@lokitech.com>.
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=209.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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Andrei Ivanov <my...@surfeu.fi>.
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Danny Angus <da...@apache.org>.
> This doesn't mean that it can not work better, though :-). There is a
> consideration of consistency (this is what Avalon and frameworks basically
> about). I conclude that RemoteDelivery implementation is not
> consistent with
> Phoenix-Cornerstone in particular and Avalon framework in general.
We'd be pleased to accept your kind offer to contribute... ;-D
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi,
I am monitoring discussions here for a quite along time.
>
> There have been discussions about this, however the fact is that it works,
> its stable, and if it ain't broke, don't fix it.
>
This doesn't mean that it can not work better, though :-). There is a
consideration of consistency (this is what Avalon and frameworks basically
about). I conclude that RemoteDelivery implementation is not consistent with
Phoenix-Cornerstone in particular and Avalon framework in general.
> We've had a few discussions about the use of JavaMail, why would you think
> we should not use it?
Because this way we don't have control on how sockets are created. Try to
implement SSL for present RemoteDelivery :-)
Andrei
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Threads in James: Re: Tomcat + James in a single jvm process
Posted by Danny Angus <da...@apache.org>.
> When I came across with this phrase. Do you mean same way as threads
> created in RemoteDelivery? I don't think this is a right way. My
> opinion is
> that RemoteDelivery needs to be refactored asap.
There have been discusions about this, however the fact is that it works,
its stable, and if it ain't broke, don't fix it.
> It shall use
> Phoenix-Excalibur threads and it shall not use JavaMail for SMTP transport
> (cornerstone socket factory shall be used instead)
We've had a few discussions about the use of JavaMail, why would you think
we should not use it?
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>