If you mean copy them to your test env, yes you can, but I expect the queues will give the same result as on your prod env.
Double check which queues you read via JMX (as there are many, you could have read the bad one). Thx, Eric On 20/11/2012 07:17, Markus Moldaschl wrote: > Yes, var/store/activemq/brokers/james is still there ... with kr-store/data, > kr-store/state and journal with some binary files in it. Can I use them for > further analysis or maybe to resend messages which were not delivered? > > Thx > Markus > > > > -----Urspr�ngliche Nachricht----- > Von: Eric Charles [mailto:[email protected]] > Gesendet: Montag, 19. November 2012 19:09 > An: James Users List > Betreff: Re: AW: AW: Outgoing queue and var/store/activemq/blob-transfer out > of sync? > > Those numbers are there to allow some distributions of the blob > (attachements) when queing the messages so we don't put all mails in the same > folder when James is under load (custom blobtransferpolicy). > > It has nothing to do with the queues. > > Do you still have the var/store/activemq/brokers/james folder? > > Thx, Eric > > On 19/11/2012 17:29, Markus Moldaschl wrote: >> james-server.log confirmes that max retries has not been reached. >> >> However, I wonder why there are folders with names 1 - 10 in >> var/store/activemq/blob-transfer and not 'outgoing' and 'spool' as stated in >> var/store/README.txt ... and I couldn't figure out what these numbers mean? >> >> Thx >> Markus >> >> >> >> -----Ursprngliche Nachricht----- >> Von: Eric Charles [mailto:[email protected]] >> Gesendet: Montag, 19. November 2012 15:33 >> An: James Users List >> Betreff: Re: AW: Outgoing queue and var/store/activemq/blob-transfer out of >> sync? >> >> It should have kept the outgoing queues, except if the number of max retries >> has been reached. >> >> Those queues are kept under in a kahadb under folder. >> >> Thx, Eric >> >> >> On 19/11/2012 11:56, Markus Moldaschl wrote: >>> Hi, >>> >>> yes, but the test env has its own dataset. I was not able to reproduce the >>> problem on the test env because there it works as expected. >>> >>> So it seems to me that for some reason the outgoing queue (on our >>> production system) was cleared somehow ... any other ideas? >>> >>> Thx >>> Markus >>> >>> >>> >>> -----Ursprngliche Nachricht----- >>> Von: Eric Charles [mailto:[email protected]] >>> Gesendet: Montag, 19. November 2012 11:24 >>> An: James Users List >>> Betreff: Re: Outgoing queue and var/store/activemq/blob-transfer out of >>> sync? >>> >>> Hi, >>> Do you mean that you are able to see the mails in the ougoing queue via JMX >>> on the replicated test env, and not on the production env? >>> >>> Thx, Eric >>> >>> On 19/11/2012 10:09, Markus Moldaschl wrote: >>>> Hi, >>>> >>>> >>>> >>>> we're using James 3.0-beta3. Last week a misconfiguration in the >>>> infrastructure lead to the problem that James could not connect to >>>> the remote gateway. I learned that this is not a big deal, as James >>>> stores the mails in the outgoing queue. We finally configured a >>>> different remote gateway to fix our bug in the infrastructure. >>>> >>>> >>>> >>>> Our problem is that the outgoing queue is emtpy (I checked it >>>> through >>>> JMX) but there are hundreds of files in >>>> var/store/activemq/blob-transfer, which I guess are the emails we >>>> did not delivery. >>>> >>>> >>>> >>>> I was able to readjust our buggy situation from production on a test >>>> system and there james works as expected. The outgoing queue and the >>>> elements in var/store/activemq/blob-transfer are in sync. >>>> >>>> >>>> >>>> Is this an indicator for a problem or am I completly wrong? >>>> >>>> >>>> >>>> Thx >>>> >>>> Markus >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > --------------------------------------------------------------------- > 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]
