You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-user@james.apache.org by "USHAKOV, Sergey" <s....@chemitech.ru> on 2011/05/03 07:01:51 UTC
Fw: M3-SNAPSHOT: mail queue management and debugging
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
Hi Stefano, thanks for responding.
Could you kindly explain what a lock is with respect to mail (if anything
special), and if a matcher/mailet can lock a mail otherwise than by trivial
looping?
Thanks and best regards,
Sergey
----- Original Message -----
From: "Stefano Bagnara" <ap...@bago.org>
To: "James Users List" <se...@james.apache.org>
Sent: Sunday, May 08, 2011 2:34 PM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
> 2011/5/8 USHAKOV, Sergey <s....@chemitech.ru>:
>> Hi Norman,
>>
>> I have more news. I have disabled _all_ my new matchers, including those
>> that worked smoothly for a month already, and this released the two mails
>> that stuck.
>
> First thing: check your mailets are thread safe (E.g: don't use mailet
> fields to store state or make sure to access them in a thread safe
> way).
>
>> By the moment my JAMES is running smoothly again, with all my old
>> matchers
>> intact, and the new matcher fixed and arranged for better debugging.
>>
>> Well, I can admit that it were my matchers who blocked these two mails
>> somehow (can't imagine how yet), but I wonder why did the other mails
>> manage to get through only after a flush and restart?
>
> Maybe your mailets had a lock on that mails.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Stefano Bagnara <ap...@bago.org>.
2011/5/8 USHAKOV, Sergey <s....@chemitech.ru>:
> Hi Norman,
>
> I have more news. I have disabled _all_ my new matchers, including those
> that worked smoothly for a month already, and this released the two mails
> that stuck.
First thing: check your mailets are thread safe (E.g: don't use mailet
fields to store state or make sure to access them in a thread safe
way).
> By the moment my JAMES is running smoothly again, with all my old matchers
> intact, and the new matcher fixed and arranged for better debugging.
>
> Well, I can admit that it were my matchers who blocked these two mails
> somehow (can't imagine how yet), but I wonder why did the other mails
> manage to get through only after a flush and restart?
Maybe your mailets had a lock on that mails.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
Hi Norman,
I have more news. I have disabled _all_ my new matchers, including those
that worked smoothly for a month already, and this released the two mails
that stuck.
By the moment my JAMES is running smoothly again, with all my old matchers
intact, and the new matcher fixed and arranged for better debugging.
Well, I can admit that it were my matchers who blocked these two mails
somehow (can't imagine how yet), but I wonder why did the other mails
manage to get through only after a flush and restart?
Regards,
Sergey
----- Original Message -----
From: "USHAKOV, Sergey" <s....@chemitech.ru>
To: "James Users List" <se...@james.apache.org>
Sent: Saturday, May 07, 2011 9:06 PM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
> Hi Norman,
>
> my latest news are the following:
>
> 1) adding <amq:prefetchPolicy> as per your inctructions did not change
> anything
> 2) if a new mail is submitted to the spool via SMTP, it gets stuck
> together with two oldtimer mails
> 3) after a flush() and server restart this new mail gets released and
> passed through, while the 2 oldtimers continue sitting in the queue in
> 'root' state...
>
> Any ideas on more tests to be performed?
>
> Regards,
> Sergey
>
>
> ----- Original Message -----
> From: "USHAKOV, Sergey" <s....@chemitech.ru>
> To: "James Users List" <se...@james.apache.org>
> Sent: Saturday, May 07, 2011 12:52 AM
> Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
>
>
>> Done. Now it is even more interesting. I have restarted JAMES and made a
>> JMX flush() on queue/spool several times, but these two mails are still
>> silently sitting in the spool in 'root' state... No exceptions now in the
>> logs meanwhile...
>>
>> Some more experiments or observations to perform? My JAMES is out of
>> production now, so please feel free to make suggestions...
>>
>> Regards,
>> Sergey
>>
>>
>> ----- Original Message -----
>> From: "Norman Maurer" <no...@googlemail.com>
>> To: "James Users List" <se...@james.apache.org>
>> Sent: Friday, May 06, 2011 11:49 PM
>> Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
>>
>>
>>> This tells me that the spooling is hanging somewhere.. as it started
>>> to process the two messages but seems to stuck..
>>>
>>> Can you remove your custom mailets/matchers and try again ?
>>>
>>> Bye,
>>> Norman
>>>
>>>
>>> 2011/5/6 USHAKOV, Sergey <s....@chemitech.ru>:
>>>> 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"
>>>> <no...@googlemail.com>
>>>> To: "James Users List" <se...@james.apache.org>
>>>> 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 <s....@chemitech.ru>:
>>>>>>
>>>>>> Hi Norman, my answers are also inside...
>>>>>>
>>>>>> ----- Original Message ----- From: "Norman Maurer"
>>>>>> <no...@googlemail.com>
>>>>>> To: "James Users List" <se...@james.apache.org>
>>>>>> 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"
>>>>>>> <no...@googlemail.com>
>>>>>>> To: "James Users List" <se...@james.apache.org>
>>>>>>> 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 <no...@googlemail.com>:
>>>>>>>>
>>>>>>>> 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 <no...@googlemail.com>:
>>>>>>>>>
>>>>>>>>> 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 <s....@chemitech.ru>:
>>>>>>>>>>
>>>>>>>>>> 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: server-user-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
Hi Norman,
my latest news are the following:
1) adding <amq:prefetchPolicy> as per your inctructions did not change
anything
2) if a new mail is submitted to the spool via SMTP, it gets stuck together
with two oldtimer mails
3) after a flush() and server restart this new mail gets released and passed
through, while the 2 oldtimers continue sitting in the queue in 'root'
state...
Any ideas on more tests to be performed?
Regards,
Sergey
----- Original Message -----
From: "USHAKOV, Sergey" <s....@chemitech.ru>
To: "James Users List" <se...@james.apache.org>
Sent: Saturday, May 07, 2011 12:52 AM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
> Done. Now it is even more interesting. I have restarted JAMES and made a
> JMX flush() on queue/spool several times, but these two mails are still
> silently sitting in the spool in 'root' state... No exceptions now in the
> logs meanwhile...
>
> Some more experiments or observations to perform? My JAMES is out of
> production now, so please feel free to make suggestions...
>
> Regards,
> Sergey
>
>
> ----- Original Message -----
> From: "Norman Maurer" <no...@googlemail.com>
> To: "James Users List" <se...@james.apache.org>
> Sent: Friday, May 06, 2011 11:49 PM
> Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
>
>
>> This tells me that the spooling is hanging somewhere.. as it started
>> to process the two messages but seems to stuck..
>>
>> Can you remove your custom mailets/matchers and try again ?
>>
>> Bye,
>> Norman
>>
>>
>> 2011/5/6 USHAKOV, Sergey <s....@chemitech.ru>:
>>> 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"
>>> <no...@googlemail.com>
>>> To: "James Users List" <se...@james.apache.org>
>>> 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 <s....@chemitech.ru>:
>>>>>
>>>>> Hi Norman, my answers are also inside...
>>>>>
>>>>> ----- Original Message ----- From: "Norman Maurer"
>>>>> <no...@googlemail.com>
>>>>> To: "James Users List" <se...@james.apache.org>
>>>>> 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"
>>>>>> <no...@googlemail.com>
>>>>>> To: "James Users List" <se...@james.apache.org>
>>>>>> 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 <no...@googlemail.com>:
>>>>>>>
>>>>>>> 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 <no...@googlemail.com>:
>>>>>>>>
>>>>>>>> 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 <s....@chemitech.ru>:
>>>>>>>>>
>>>>>>>>> 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: server-user-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
Done. Now it is even more interesting. I have restarted JAMES and made a JMX
flush() on queue/spool several times, but these two mails are still silently
sitting in the spool in 'root' state... No exceptions now in the logs
meanwhile...
Some more experiments or observations to perform? My JAMES is out of
production now, so please feel free to make suggestions...
Regards,
Sergey
----- Original Message -----
From: "Norman Maurer" <no...@googlemail.com>
To: "James Users List" <se...@james.apache.org>
Sent: Friday, May 06, 2011 11:49 PM
Subject: Re: Fw: M3-SNAPSHOT: mail queue management and debugging
> This tells me that the spooling is hanging somewhere.. as it started
> to process the two messages but seems to stuck..
>
> Can you remove your custom mailets/matchers and try again ?
>
> Bye,
> Norman
>
>
> 2011/5/6 USHAKOV, Sergey <s....@chemitech.ru>:
>> 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"
>> <no...@googlemail.com>
>> To: "James Users List" <se...@james.apache.org>
>> 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 <s....@chemitech.ru>:
>>>>
>>>> Hi Norman, my answers are also inside...
>>>>
>>>> ----- Original Message ----- From: "Norman Maurer"
>>>> <no...@googlemail.com>
>>>> To: "James Users List" <se...@james.apache.org>
>>>> 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"
>>>>> <no...@googlemail.com>
>>>>> To: "James Users List" <se...@james.apache.org>
>>>>> 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 <no...@googlemail.com>:
>>>>>>
>>>>>> 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 <no...@googlemail.com>:
>>>>>>>
>>>>>>> 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 <s....@chemitech.ru>:
>>>>>>>>
>>>>>>>> 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: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Norman Maurer <no...@googlemail.com>.
This tells me that the spooling is hanging somewhere.. as it started
to process the two messages but seems to stuck..
Can you remove your custom mailets/matchers and try again ?
Bye,
Norman
2011/5/6 USHAKOV, Sergey <s....@chemitech.ru>:
> 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"
> <no...@googlemail.com>
> To: "James Users List" <se...@james.apache.org>
> 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 <s....@chemitech.ru>:
>>>
>>> Hi Norman, my answers are also inside...
>>>
>>> ----- Original Message ----- From: "Norman Maurer"
>>> <no...@googlemail.com>
>>> To: "James Users List" <se...@james.apache.org>
>>> 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"
>>>> <no...@googlemail.com>
>>>> To: "James Users List" <se...@james.apache.org>
>>>> 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 <no...@googlemail.com>:
>>>>>
>>>>> 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 <no...@googlemail.com>:
>>>>>>
>>>>>> 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 <s....@chemitech.ru>:
>>>>>>>
>>>>>>> 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: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
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" <no...@googlemail.com>
To: "James Users List" <se...@james.apache.org>
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 <s....@chemitech.ru>:
>> Hi Norman, my answers are also inside...
>>
>> ----- Original Message ----- From: "Norman Maurer"
>> <no...@googlemail.com>
>> To: "James Users List" <se...@james.apache.org>
>> 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"
>>> <no...@googlemail.com>
>>> To: "James Users List" <se...@james.apache.org>
>>> 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 <no...@googlemail.com>:
>>>>
>>>> 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 <no...@googlemail.com>:
>>>>>
>>>>> 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 <s....@chemitech.ru>:
>>>>>>
>>>>>> 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: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Norman Maurer <no...@googlemail.com>.
Im interested in "CurrentSpoolCount"...
Thanks,
Norman
2011/5/4 USHAKOV, Sergey <s....@chemitech.ru>:
> Hi Norman, my answers are also inside...
>
> ----- Original Message ----- From: "Norman Maurer"
> <no...@googlemail.com>
> To: "James Users List" <se...@james.apache.org>
> 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"
>> <no...@googlemail.com>
>> To: "James Users List" <se...@james.apache.org>
>> 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 <no...@googlemail.com>:
>>>
>>> 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 <no...@googlemail.com>:
>>>>
>>>> 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 <s....@chemitech.ru>:
>>>>>
>>>>> 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: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
Hi Norman, my answers are also inside...
----- Original Message -----
From: "Norman Maurer" <no...@googlemail.com>
To: "James Users List" <se...@james.apache.org>
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"
> <no...@googlemail.com>
> To: "James Users List" <se...@james.apache.org>
> 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 <no...@googlemail.com>:
>>
>> 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 <no...@googlemail.com>:
>>>
>>> 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 <s....@chemitech.ru>:
>>>>
>>>> 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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Norman Maurer <no...@googlemail.com>.
Hi,
comments inside..
2011/5/4 USHAKOV, Sergey <s....@chemitech.ru>:
> Thank you Norman, the idea to do a "flush" did the job. Not immediately
> though, but after a restart.
>
> You are also right that at origin of the issue is somewhere in my matchers,
> as after restart I immediately got an exception in my new matcher.
So after you remove the matcher you don'T see any messages "stuck" ?
>
> There is no case for me immediately to make a check of replacing the
> "amq:connectionFactory", at least before I get rid of the exception(s) in
> the matcher. Still would you like me to make such a test later? Or maybe
> before? :)
>
> 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)
>
> Regards,
> Sergey
>
>
> ----- Original Message ----- From: "Norman Maurer"
> <no...@googlemail.com>
> To: "James Users List" <se...@james.apache.org>
> 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 <no...@googlemail.com>:
>>
>> 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 <no...@googlemail.com>:
>>>
>>> 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 <s....@chemitech.ru>:
>>>>
>>>> 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: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by "USHAKOV, Sergey" <s....@chemitech.ru>.
Thank you Norman, the idea to do a "flush" did the job. Not immediately
though, but after a restart.
You are also right that at origin of the issue is somewhere in my matchers,
as after restart I immediately got an exception in my new matcher.
There is no case for me immediately to make a check of replacing the
"amq:connectionFactory", at least before I get rid of the exception(s) in
the matcher. Still would you like me to make such a test later? Or maybe
before? :)
Answering your question about thread count. JMX reports 20 (the default
value).
Regards,
Sergey
----- Original Message -----
From: "Norman Maurer" <no...@googlemail.com>
To: "James Users List" <se...@james.apache.org>
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 <no...@googlemail.com>:
> 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 <no...@googlemail.com>:
>> 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 <s....@chemitech.ru>:
>>> 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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Norman Maurer <no...@googlemail.com>.
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 <no...@googlemail.com>:
> 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 <no...@googlemail.com>:
>> 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 <s....@chemitech.ru>:
>>> 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
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-user-help@james.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Norman Maurer <no...@googlemail.com>.
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 <no...@googlemail.com>:
> 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 <s....@chemitech.ru>:
>> 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
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-user-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org
Re: Fw: M3-SNAPSHOT: mail queue management and debugging
Posted by Norman Maurer <no...@googlemail.com>.
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 <s....@chemitech.ru>:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
> For additional commands, e-mail: server-user-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org