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]
