You missed my comment about the 'message_state' is still set to 'transport'.
The retry count is null. That only appears to be set when the message
state is 'error'.
On 99% of these, there is no attempt in the logs anywhere of it ever trying
to send. It hasn't tried and failed. It never tried.
From: Stefano Bagnara <[EMAIL PROTECTED]>
Reply-To: "James Users List" <[email protected]>
To: James Users List <[email protected]>
Subject: Re: HELP!! Thousands of files stuck in spool at 'transport' state
Date: Fri, 16 Jun 2006 20:00:16 +0200
James uses a retry scheduling.
The first retry is done after 5 minutes from the first attempt, then 10,
and so on:
<delayTime> 5 minutes </delayTime>
<delayTime> 10 minutes </delayTime>
<delayTime> 45 minutes </delayTime>
<delayTime> 2 hours </delayTime>
<delayTime> 3 hours </delayTime>
<delayTime> 6 hours </delayTime>
<maxRetries> 25 </maxRetries>
You can look at the "error_message" column (if you use db repositories) to
know what is the current attempt.
If you had network problems for the first 6 hours, you now have all the
messages at the 6th or 7th attempts and James will try them only every 6
hours.
There is also a bug in the outgoing spooling that may delay much more the
messages if you don't send new messages to the outgoing spool (I fixed this
few weeks ago).
Stefano
randy roy wrote:
sorry... in my panic i forgot the useful info... Windows server 2003,
james
2.2.0.0a17
Nothing out of the ordinary in the config. Pretty basic config with
typical
spam check mailets. About 40 domains are hosted. Again this has worked
for
weeks since any change, and has worked for years overall.
Don't see anything wrong with the DNS. (I can get to web sites from the
browser)... Again, there are NO error messages anywhere. Every time I
restart the server, it tries one outgoing (the same one each time). It
says
it can't connect to port 25 on the ip address. Tries several times, and
that's the last thing delivery attempt. Granted the IP address for the
target may be bogus (a lot of these are spam bounces...). But why would
James decide not to continue to the next outgoing email. I know for a
fact
that many of the queued up emails are valid ip addresses.
From the logs it looks about about 4 emails got sent out around 5am. Why
it
decided to try to send a 3 or 4 at that time and then stop is puzzling.
The
previous successful send was around 11pm last night.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
