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 Michael Enevold <me...@2ndc.dk> on 2002/11/27 08:21:28 UTC
regarding nntp error with "james" on NetWare 6
Hi "james-dev" list
I have done some testing with "James" running on a NW6 box.
And I can get it up running with the JVM 1.4 on the NW 6 box.
but If I then tries to access the prebuild in news groups within the
James server
with a Morzilla 1.0 news reader then I get these errors (see attached
*.jpg's)
This is done from a w2000 pro workstation, with the IP of the NW6 box
and not LocalHost
any ideas!
- Michael
Re: regarding nntp error with "james" on NetWare 6
Posted by Harmeet Bedi <ha...@kodemuse.com>.
What version, build etc. of James are you using ?
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: SQL DOWN; MAIL LOST?
Posted by Serge Knystautas <se...@lokitech.com>.
Yes, sorry... Danny's hit the nail on the thread. My db pool can't handle a
complete DB outage, so if you cycle the DB server, you have to cycle James.
Like Danny said, this will be replaced. Aside from more robustness, I'm
also looking for javax.sql.DataSource support so we can make databases more
available to mailets.
Serge Knystautas
Loki Technologies
http://www.lokitech.com
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Friday, December 06, 2002 5:09 AM
Subject: RE: SQL DOWN; MAIL LOST?
Alan,
Looking at this again I think I know what you're seeing, it looks like James
connection pool is not capable of recognising that the db has gone away, and
that the connections all have to be re-made.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] mailet API
Posted by "Noel J. Bergman" <no...@devtech.com>.
Update made. Please review from the CVS. [Yesterday, it took 24 hours
before I saw a cvs commit message]
I don't want to talk it down at all! I'm talking it up, in fact.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Friday, December 06, 2002 18:13
To: James Developers List
Subject: RE: [PATCH] mailet API
yup. 100%
I just don't think it makes "marketing" sense to talk down our own product
during the launch of a new version, is all.
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 06 December 2002 20:23
> To: James Developers List
> Subject: RE: [PATCH] mailet API
>
> Does this:
>
> <p>The Mailet API is currently in its second revision. Although,
> the Mailet
> API is expected to undergo substantial changes in the near
> future, it is our
> aim that existing Mailets that abided purely by the prior Mailet API
> interfaces will continue to run with the revised specification.</p>
>
> meet with your approval?
>
> --- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] mailet API
Posted by Danny Angus <da...@apache.org>.
yup. 100%
I just don't think it makes "marketing" sense to talk down our own product during the launch of a new version, is all.
d.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 06 December 2002 20:23
> To: James Developers List
> Subject: RE: [PATCH] mailet API
>
>
>
> Does this:
>
> <p>The Mailet API is currently in its second revision. Although,
> the Mailet
> API is expected to undergo substantial changes in the near
> future, it is our
> aim that existing Mailets that abided purely by the prior Mailet API
> interfaces will continue to run with the revised specification.</p>
>
> meet with your approval?
>
> --- Noel
>
>
> --
> 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: [PATCH] mailet API
Posted by "Noel J. Bergman" <no...@devtech.com>.
Does this:
<p>The Mailet API is currently in its second revision. Although, the Mailet
API is expected to undergo substantial changes in the near future, it is our
aim that existing Mailets that abided purely by the prior Mailet API
interfaces will continue to run with the revised specification.</p>
meet with your approval?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] mailet API
Posted by Danny Angus <da...@apache.org>.
> If what we are trying to say is that the revised Mailet API will still run
> existing Mailets that abided purely by the prior Mailet API interfaces, I
> think we're in agreement.
Thats what I wanted to emphasise, its not at all clear from the existing doc.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] mailet API
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
If what we are trying to say is that the revised Mailet API will still run
existing Mailets that abided purely by the prior Mailet API interfaces, I
think we're in agreement. I see no reason to break that compatibility.
I think that most of the radical surgery within James will be in specific
areas of the internals.
--- Noel
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Friday, December 06, 2002 11:02
To: James Developers List
Subject: RE: [PATCH] mailet API
> In what sense? A mailet that uses the new Mailet API won't be capable of
> running on older versions of James, and an older mailet that goes
> beyond the
> Mailet API and accesses Avalon resources directly may not be able to work
> after introducing a portable solution.
But an older mailet that *doesn't* go beyond the existing API will be able
to.
Just because some do doesn't mean that all do.
There's no reason why James shouldn't support both versions, and some
compelling reasons why it should.
>
> Do we want to continue to permit this:
>
> ComponentManager compMgr =
> (ComponentManager)getMailetContext().getAttribute(Constants.AVALON
> _COMPONENT
> _MANAGER);
>
No, we dont, this is already established since idontknowwhenthehellago as
you well know.
> Maybe ... maybe not. I think we have a lot to discuss, and I wasn't
> planning to make any a priori assumptions.
By which standards peters documentation shouldn't be making any claims about
the API changing or not.
I merely thought it would be prudent not to propogate the impression that
the API was about to undergo radical surgery that would break everything
that has gone before.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] mailet API
Posted by Danny Angus <da...@apache.org>.
> In what sense? A mailet that uses the new Mailet API won't be capable of
> running on older versions of James, and an older mailet that goes
> beyond the
> Mailet API and accesses Avalon resources directly may not be able to work
> after introducing a portable solution.
But an older mailet that *doesn't* go beyond the existing API will be able to.
Just because some do doesn't mean that all do.
There's no reason why James shouldn't support both versions, and some compelling reasons why it should.
>
> Do we want to continue to permit this:
>
> ComponentManager compMgr =
> (ComponentManager)getMailetContext().getAttribute(Constants.AVALON
> _COMPONENT
> _MANAGER);
>
No, we dont, this is already established since idontknowwhenthehellago as you well know.
> Maybe ... maybe not. I think we have a lot to discuss, and I wasn't
> planning to make any a priori assumptions.
By which standards peters documentation shouldn't be making any claims about the API changing or not.
I merely thought it would be prudent not to propogate the impression that the API was about to undergo radical surgery that would break everything that has gone before.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [PATCH] mailet API
Posted by "Noel J. Bergman" <no...@devtech.com>.
> A small point but I think mailet is on v2 already.
> And we did approve the notion of making changes backwards
> compatible didn't we?
In what sense? A mailet that uses the new Mailet API won't be capable of
running on older versions of James, and an older mailet that goes beyond the
Mailet API and accesses Avalon resources directly may not be able to work
after introducing a portable solution.
Do we want to continue to permit this:
ComponentManager compMgr =
(ComponentManager)getMailetContext().getAttribute(Constants.AVALON_COMPONENT
_MANAGER);
Maybe ... maybe not. I think we have a lot to discuss, and I wasn't
planning to make any a priori assumptions.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[PATCH] mailet API
Posted by Danny Angus <da...@apache.org>.
Sending a patch so we can agree on this..
A small point but I think mailet is on v2 already.
And we did approve the notion of making changes backwards compatible didn't we?
d.
Index: mailet_api_2_1.xml
===================================================================
RCS file: /home/cvs/jakarta-james/src/xdocs/mailet_api_2_1.xml,v
retrieving revision 1.1
diff -u -r1.1 mailet_api_2_1.xml
--- mailet_api_2_1.xml 1 Dec 2002 09:55:00 -0000 1.1
+++ mailet_api_2_1.xml 6 Dec 2002 11:20:22 -0000
@@ -1,12 +1,12 @@
-<?xml version="1.0"?>
-
-<document>
-
- <properties>
- <title>James 2.1 - Mailet API</title>
- </properties>
+<?xml version="1.0"?>
-<body>
+<document>
+
+ <properties>
+ <title>James 2.1 - Mailet API</title>
+ </properties>
+
+<body>
<section name="Mailet API">
<p>The Mailet API is a simple API used to build mail processing applications. James is a Mailet
container, allowing administrators to deploy Mailets (both custom and pre-made) to carry out a
@@ -22,11 +22,12 @@
<p>Mailets are responsible for actually processing the message. They may alter the message in any fashion,
or pass the message to an external API or component. This can include delivering a message to its destination
repository or SMTP server.</p>
-<p>The Mailet API is currently in its first revision, and is expected to undergo substantial changes
-in the near future. The Javadoc for the Mailet API can be found <a href="/mailet/index.html">here</a>.</p>
-<p>James bundles a number of Matchers and Mailets in its distribution. Descriptions of provided matchers
+<p>The Mailet API is currently in its second revision. It is expected to undergo substantial changes
+in the near future, it is our aim that these will be backwards compatible with the current version.
+<br/>The Javadoc for the Mailet API can be found <a href="/mailet/index.html">here</a>.</p>
+<p>James bundles a number of Matchers and Mailets in its distribution. Descriptions of provided matchers
can be found <a href="provided_matchers_2_1.html">here</a>, while descriptions of provided mailets can be found
<a href="provided_mailets_2_1.html">here</a>.</p>
</section>
-</body>
-</document>
+</body>
+</document>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SQL DOWN; MAIL LOST?
Posted by Danny Angus <da...@apache.org>.
Alan,
Looking at this again I think I know what you're seeing, it looks like James connection pool is not capable of recognising that the db has gone away, and that the connections all have to be re-made.
a brief test has confirmed this, the answer is that if you re-start the db you must also re-start James.
On the plus side Serge is intending to replace this code in the next cycle.
As far as missing messages are concerned the following transcript shows that James behaves acceptably (after a bad start!) in this circumstance and replies to the sender, with a 4xx code, that the service is temporarily unavailable. The sender is then responsible for re-trying later.
A slightly better solution would be to catch the SQLException and return a more meaningful message, the whole answer is to catch the exception, test the connection, and replace it with a fresh one if possible.
<< 220 killerbees.co.uk SMTP Server (JAMES SMTP Server 2.1a1-cvs) ready Fri, 6 Dec 2002 10:05:44 +0000 (GMT)
>> MAIL FROM:<danny>
<< 250 Sender <da...@localhost> OK
>> rcpt to:<danny>
<< 250 Recipient <da...@localhost> OK
>> DATA
<< 354 Ok Send data ending with <CRLF>.<CRLF>
>> testdata
>> .
<< 451 Error processing message:
<< Exception spooling message:
<< Exception caught while storing mail Container:
<< java.sql.SQLException:
<< Communication link failure:
<< java.net.SocketException; nested exception is:
<< java.lang.RuntimeException:
<< Exception caught while storing mail Container:
<< java.sql.SQLException: Communication link failure: java.net.SocketException
>> quit
<< 221 killerbees.co.uk Service closing transmission channel
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SQL DOWN; MAIL LOST?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> i would have thought that an error message of NO RECIPIENT
You have to configure the bounce message if you want it. There is no bounce
by default. I don't know why not, but I suspect because of anti-spam
concerns the default configuration is more oriented to avoid spam than what
I consider to be correct behavior (reliable delivery/notification).
HOWEVER, if the SMTP handler could not post a NEW message into the spool, it
should provide an immediate error notice to the e-mail client, so no mail
should be lost.
In any event, what did appear in your logs? For which repositories are you
using MSSQL?
> unfortunately, i have had the reverse experience with MySQL
When was that? For a long time, Windows was not a primary focus of the
MySQL developers, but it is now an equal platform.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SQL DOWN; MAIL LOST?
Posted by Alan Gerhard <al...@GerCom.Com>.
U-WROTE:
if (!errors.isEmpty()) {
getMailetContext().sendMail(mail.getSender(),
errors, mail.getMessage(),Mail.ERROR);
}
So in the event of an exception from the JDBC layer, we SHOULD be logging
the exception and posting the mail to the error processor, so you should
find the e-mails in your error repository. Of course, if the spooler is
also using JDBC, then we can't do that (but nor would we be able to receive
new e-mails), nor can we store it in the error repository if THAT store uses
JDBC.
I-WRITE:
hmmmm..... i would have thought that an error message of NO RECIPIENT (or
something like that)
would be sent to the sender... the idea is that i would not want to accept the
message if i cannot process it.
the way it seems is that James will accept everything and then process it
later - IF CONFIGURED PROPERLY\, otherwise the accepted mail is lost.
U-WROTE:
By the way, must you use MSSQL? I hear nothing (absolutely nothing) good
about the JDBC drivers for MSSQL. I can tell you that in my own testing
with MySQL, I have pumped millions of messages. My last stress test ran 40
hours and roughly 4 million messages. Success breeds trust.
I-WRITE:
um, well, no, not really. M$SQL is already on the box and used. unfortunately, i
have had the reverse experience with MySQL where it was(is) not stable at all
running in a WinTel environment... but that too can be INCORRECTLY CONFIGURED..
alan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: SQL DOWN; MAIL LOST?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Well, let's check LocalDelivery:
public void service(Mail mail) throws MessagingException {
Collection recipients = mail.getRecipients();
Collection errors = new Vector();
for (Iterator i = recipients.iterator(); i.hasNext(); ) {
MailAddress recipient = (MailAddress) i.next();
try {
getMailetContext().storeMail(mail.getSender(), recipient,
mail.getMessage());
} catch (Exception ex) {
getMailetContext().log("Error while storing mail.", ex);
errors.add(recipient);
}
}
if (!errors.isEmpty()) {
// If there were errors, we redirect the email to the ERROR
processor.
// In order for this server to meet the requirements of the SMTP
specification,
// mails on the ERROR processor must be returned to the sender.
Note that this
// email doesn't include any details regarding the details of
the failure(s).
// In the future we may wish to address this.
getMailetContext().sendMail(mail.getSender(),
errors, mail.getMessage(),
Mail.ERROR);
}
So in the event of an exception from the JDBC layer, we SHOULD be logging
the exception and posting the mail to the error processor, so you should
find the e-mails in your error repository. Of course, if the spooler is
also using JDBC, then we can't do that (but nor would we be able to receive
new e-mails), nor can we store it in the error repository if THAT store uses
JDBC.
So ... how are your stores configured, and what do you see in the logs?
As for the rejection notice, check the comment (above). It is your
responsibility to properly configure the error processor. We will probably
enhance this area for v3.
By the way, must you use MSSQL? I hear nothing (absolutely nothing) good
about the JDBC drivers for MSSQL. I can tell you that in my own testing
with MySQL, I have pumped millions of messages. My last stress test ran 40
hours and roughly 4 million messages. Success breeds trust.
--- Noel
-----Original Message-----
From: Alan Gerhard [mailto:alan.gerhard@GerCom.Com]
Sent: Wednesday, December 04, 2002 23:00
To: 'James Developers List'
Subject: SQL DOWN; MAIL LOST?
James 2.0a3 - recompiled and running
setup MSSQL for mail boxes
all is working more or less okay.
SQL crashed - 6 hours later James' JVM died.
Hmm .... was anything lost ??
tested :
stopped SQL
sendmailserverONE sent msg to James; received an OK from James
hm.... where did it go ??
started SQL and a reset of James was necessary. it appears that the spool we
lost or that the mail was processed positively but it wasn't able to deliver
to
the pop3 mailbox.
is this a James issue or my inability to properly configure the necessary
mailets?
this is what i have -
<!-- Processor CONFIGURATION SAMPLE: transport is a sample custom
processor for local or remote delivery -->
<processor name="transport">
<!-- Is the recipient is for a local account, deliver it
locally -->
<mailet match="RecipientIsLocal" class="LocalDelivery">
</mailet>
<!-- If the host is handled by this server and it did not get
locally delivered, this is an invalid recipient
<mailet match="HostIsLocal" class="ToProcessor">
<processor>error</processor>
</mailet> but we kill this shit ... -->
<mailet match="HostIsLocal" class="Null">
</mailet
and by looking at it i see the error of my ways..
in any case, the question is : if the local recipient is not available
because
the mailbox is down, shouldn't we sent back a rejection ?? or is that me
again
with the inability to properly set this puppy up ?? :->
thanks,
alan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
SQL DOWN; MAIL LOST?
Posted by Alan Gerhard <al...@GerCom.Com>.
James 2.0a3 - recompiled and running
setup MSSQL for mail boxes
all is working more or less okay.
SQL crashed - 6 hours later James' JVM died.
Hmm .... was anything lost ??
tested :
stopped SQL
sendmailserverONE sent msg to James; received an OK from James
hm.... where did it go ??
started SQL and a reset of James was necessary. it appears that the spool we
lost or that the mail was processed positively but it wasn't able to deliver to
the pop3 mailbox.
is this a James issue or my inability to properly configure the necessary
mailets?
this is what i have -
<!-- Processor CONFIGURATION SAMPLE: transport is a sample custom
processor for local or remote delivery -->
<processor name="transport">
<!-- Is the recipient is for a local account, deliver it locally -->
<mailet match="RecipientIsLocal" class="LocalDelivery">
</mailet>
<!-- If the host is handled by this server and it did not get
locally delivered, this is an invalid recipient
<mailet match="HostIsLocal" class="ToProcessor">
<processor>error</processor>
</mailet> but we kill this shit ... -->
<mailet match="HostIsLocal" class="Null">
</mailet
and by looking at it i see the error of my ways..
in any case, the question is : if the local recipient is not available because
the mailbox is down, shouldn't we sent back a rejection ?? or is that me again
with the inability to properly set this puppy up ?? :->
thanks,
alan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>