Yes, that was strange. Ok. I have not been able to get the timeout error again.
I believe yesterday when I tested with the james server restart, I may have restarted user-adder. I can't other wise explain why it worked. Today I created a user. (which worked without timeout after 12 hours). I immediately killed james and restarted it 10 seconds later. (sockets) Attempted to create another user and got a jmx exception. So. At this point I believe my e-mail from yesterday gave incorrect information. -- At this point, I would guess that: 1. I remember the initial exception incorrectly, and that I never got a timeout. I could have just gotten a connection problem, and I mentally inserted the word timeout. 2. If there was in fact a timeout, perhaps I had killed the James server, and somehow, as the connection timed out, and tried to reconnect it caught this exception and attributed it to timeout, where in fact it was a missing James Server, or a restarted name server. Anyhow. If I ever see the timeout again I will save the log! -tim On Jun 21, 2012, at 1:39 AM, Eric Charles wrote: > On 06/20/2012 10:30 PM, Timothy Prepscius wrote: >> I don't know yet. Hasn't timed out again yet. >> I hope it is not indeterminate. >> >> I just tried to create a user, and it succeeded. And it has been 8 hours >> since this morning. When I created a user. >> Hmmm, I wonder what will happen if I restart the james server. >> >> Ok, that succeeded too. >> > > Strange. I would have bet on a broken connection. > Eric > >> >> Hmm.. I don't know. I should have kept that log. >> Will let you know the next time it happens, >> >> -tim >> >> >> On Jun 20, 2012, at 5:08 AM, Eric Charles wrote: >> >>> Hi Tim, >>> >>> An indication of the time needed to get the timeout will be useful. >>> >>> We already have findbugs defines in the (project) pom, so if you invoke >>> 'mvn findbugs:check' you will get a findbugs.xml in the target folder. If >>> you want something more readable, you can invoke 'mvn site -Psite-reports' >>> (look in site/findbugs.html). >>> >>> Thx, Eric >>> >>> On 06/19/2012 06:48 PM, Timothy Prepscius wrote: >>>> K, I'll post a stack trace tomorrow. (need to wait for the connection to >>>> die) >>>> >>>> >>>> [ optional ] >>>> >>>> On a lesser note, do you guys do code coverage/static analysis of james? >>>> >>>> Do you have a favorite tool/plugin that works well with maven and james? >>>> (I'm not versed in the various maven java coverage/analysis tools) >>>> >>>> I'll spend some time looking tonight, but if there is an obvious choice.. >>>> etc etc etc.. >>>> >>>> [ /optional ] >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> -tim >>>> >>>> >>>> On Jun 19, 2012, at 10:23 AM, Eric Charles wrote: >>>> >>>>> Hi Tim, >>>>> >>>>> No idea on the overhead, the connect method instanciates a few objects >>>>> connecting to the remote server. >>>>> >>>>> If your workload is not too high, it should be all right, but don't do it >>>>> via direct database access (never ever!). >>>>> >>>>> It would be good that you post the exception stacktrace in a JIRA so we >>>>> can think to enhance the client with a JMX Connection pool (or something >>>>> like that) or configure the connection with longer timeouts. >>>>> >>>>> Thx, >>>>> Eric >>>>> >>>>> On 06/19/2012 02:58 PM, Timothy Prepscius wrote: >>>>>> I am wondering whether anyone knows the overhead associated with the >>>>>> JmxServerProbe? >>>>>> >>>>>> So, currently, I instantiate a JMX interface and keep it around >>>>>> indefinitely in order to create users. >>>>>> However, it eventually times out and fails to reconnect. >>>>>> Thereafter, user creation fails. >>>>>> >>>>>> >>>>>> So, if I use JMX, I will need to change the code to instantiate the JMX >>>>>> interface with each user creation. >>>>>> >>>>>> >>>>>> --- >>>>>> >>>>>> Is this wise? What sort of overhead am I inducing by creating this JMX >>>>>> interface? >>>>>> >>>>>> I'm wondering if I should instead just write directly to the >>>>>> james.JAMES_USER table. >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -tim >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>>>>> For additional commands, e-mail: server-user-h...@james.apache.org >>>>>> >>>>> >>>>> -- >>>>> eric | http://about.echarles.net | @echarles >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>>>> For additional commands, e-mail: server-user-h...@james.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>>> For additional commands, e-mail: server-user-h...@james.apache.org >>>> >>> >>> -- >>> eric | http://about.echarles.net | @echarles >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >>> For additional commands, e-mail: server-user-h...@james.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org >> For additional commands, e-mail: server-user-h...@james.apache.org >> > > -- > eric | http://about.echarles.net | @echarles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
