CurrentSpoolCount is 2.
If I do a browse() on org.apache.james/component/queue/spool, then I see 2
messages there, both with:
- empty 'errorMessage'
- 'nextDelivery' as -1
- 'state' as 'root'
Regards,
Sergey
----- Original Message -----
From: "Norman Maurer" <[email protected]>
To: "James Users List" <[email protected]>
Sent: Thursday, May 05, 2011 11:46 PM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Im interested in "CurrentSpoolCount"...
Thanks,
Norman
2011/5/4 USHAKOV, Sergey <[email protected]>:
Hi Norman, my answers are also inside...
----- Original Message ----- From: "Norman Maurer"
<[email protected]>
To: "James Users List" <[email protected]>
Sent: Wednesday, May 04, 2011 11:00 PM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
[...]
So after you remove the matcher you don'T see any messages "stuck" ?
Not exactly :) One message managed to escape, the remaining two are still
stuck, probably due to an exception thrown by my matcher. I let them stay
in
this state while I'm refactoring the matcher, as I have taken all the
useful
load off my JAMES for a while...
[...]
Answering your question about thread count. JMX reports 20 (the default
value).
So 20 of 20 threads are in use when it stuck ? (Just tell me the two
values displayed in JMX)
Sorry, not sure I understand which two values you mean :(
- JMX exhibits 20 for
org.apache.james/component/mailetcontainer/mailspooler/Attributes/ThreadCount
- JMX returns 20 for
org.apache.james/component/mailetcontainer/mailspooler/Operations/getThreadCount()
- "mailetcontainer.xml" has "20" as text content for
"mailetcontainer/spooler/threads" element
Are there any other JMX values to be checked?
Regards,
Sergey
Regards,
Sergey
----- Original Message ----- From: "Norman Maurer"
<[email protected]>
To: "James Users List" <[email protected]>
Sent: Tuesday, May 03, 2011 10:48 PM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
And one thing I missed before....
Could you check how many spool threads are active via jmx ?
You can find it under:
org.apache.james:type=component,component=mailetcontainer,name=mailspooler
Thanks,
Norman
2011/5/3 Norman Maurer <[email protected]>:
And another thing to try would to edit the file
"conf/context/james-server-context.xml" and replace the
"amq:connectionFactory...." entry with the following:
<amq:connectionFactory id="amqConnectionFactory"
brokerURL="vm://james?create=false">
<amq:prefetchPolicy>
<amq:prefetchPolicy queuePrefetch="1" topicPrefetch="1"/>
</amq:prefetchPolicy>
<property name="blobTransferPolicy" ref="blobTransferPolicy"/>
</amq:connectionFactory>
Bye,
Norman
2011/5/3 Norman Maurer <[email protected]>:
Hi there,
first of I never had such a problem. So here are some questions for
you so we can hopefully track it down..
1) Did you also try to "flush" the queue and see if that does start
the spooling ?
2) Do you have an special mailets/matchers (self-written) ?
Thanks,
Norman
2011/5/3 USHAKOV, Sergey <[email protected]>:
Hi all,
sorry if double-posting, as I am not sure whether my mail comes
through...
Being a newbie with JAMES, I have currently an instance of JAMES
running
in
test/semi-production mode.
Knowing for sure that some of the mails get occasionally "stuck"
inside
the
server, I have made an attempt to explore and manage the mail queues
using
JConsole.
Under the branch "org.apache.james/component/queue/spool" I have
found
an
manageable object that showed several items being present in the
queue.
I
was able to browse them. I was also offered several ways to remove
them,
but
that did not fit my intentions :)
Having made severals stops and restarts of the server, I eventually
managed
to reduce the number of the items in the queue from 26 to 2. With
every
restart the "mailetcontainer.log" reported that some of the mails
were
successfully delivered or sent out.
But it's beyond my understanding what are the remaining mails doing
silently
in the "root" state in the queue. Why nothing is reflected by the
logs?
Why
some of them get delivered upon restart, while others stay there? Is
there
any facility for not removing a mail item, but rather for
re-activating
its
processing by the spool manager, in case the mail is in some
suspended
state? It is evident by the way, that the mails remaining are
preventing
new
mails from being processed, as having sent in one more mail, I see
now
3
items in the queue...
Any ideas, as well as pointing to an appropriate manual, woulld be
most
appreciated.
Regards,
Sergey
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
