Followup... Since this is a sandbox, I'm not really worried about
totally crashing it. So I just deleted the contents of the var/mail and
var/store folders knowing they were originally empty in the distribution
zip. That 'fixed' it. At least now I'm fairly certain that it has to
do with a problem with something in the mail queue which I sent either
outbound from this installation or inbound from another installation.
So I'm going to start adding/removing mailets and try to isolate. But
I'd still like to understand if there's a better/safer way to manage the
queue rather than blowing the whole var folder away. I much prefer a
scalpel approach rather than an ax approach. Still very curious about a
'github' class being the class that this mail item was causing a crash
in james...
One other thing, just for my education... what format is the 'mail item'
that is stored in the spool queue? If an item in the queue can cause
class cast exceptions or "InvalidClassChange", etc when it is read, it
would appear to mean that the queue is maintaining classes. Does the
spool contain a java-serialized object?
Jerry
On 2/1/2020 10:47 AM, Jerry Malcolm wrote:
Hey Garry,
Thanks for the quick response. I totally omitted one important fact.
This server is a sandbox. Currently the only email it sends/receives
is me sending to/from an account I have on completely different
installation. But you got me to thinking. Perhaps sending a test
email is what is triggering the problem.
You mentioned managing the mail queue. I have had a question about
the mail queue ever since I moved off of 2.x a few years back. In 2.x
the mail queue was simply a table in the database. That's long gone
now. I suspect the spool is now being stored and managed in the var
folder. But I'm just guessing. When you say 'purge the top message
from the queue' is there some documentation on how to do that? You
also mentioned checking timeouts and tightening up relaying. Could
you elaborate? My conf /*.xml files are copied over from my function
3.4 version in my other installation. Not saying something didn't
change in 3.5 that I'm now irritating. But I'm not sure what to look
for in timeouts and relaying.
Thanks again.
Jerry
On 2/1/2020 5:39 AM, Garry Hurley wrote:
Logic requires asking these questions, so please bear with me.
You say it fails after 30 minutes... How much volume is the email
server seeing? Are you getting a huge spike in traffic, or is it just
a connection timeout?
When you look at the messages you received, are any of them weird? I
mean, is it a message from the same sender or containing an
attachment that suddenly causes the failure?
The exception you listed looks similar to a casting exception. My
guess - without digging into the code - is that there is a message
waiting to be processed that has a bad format on the queue. If you
can remove that badly formatted message, things might free up. I have
run into similar issues with custom mailets my project uses. I didn’t
write them, merely adapt them from James 2.3.2 to 3.3.0. Try checking
your timeouts, purging the top message from the queue, and tightening
up your mail relaying.
Sent from my iPad
On Feb 1, 2020, at 1:19 AM, Jerry Malcolm <techst...@malcolms.com>
wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
