I am not familiar with Doug Lea or any of his opinions. I do not have direct control of the threading of the RMI communication. The RMI method calls are asynchronous and I have to wait for the return message before I can produce the display content. I have not gone too deep into JMS to make it event driven yet. This would be my next change after I get basic functionality.
I do not directly spawn the new thread. The new thread is the RMI return message coming from a remote host. Now that I do not synchronize a method, I no longer have blocking problems and I get out of my loop as soon as the RMI thread sets a flag that the data is ready. Robert S. Harper 801.265.8800 ex. 255 > -----Original Message----- > From: Dakota Jack [mailto:[EMAIL PROTECTED] > Sent: Friday, December 10, 2004 9:21 AM > To: Tomcat Users List; [EMAIL PROTECTED] > Subject: Re: Tomcat & threads > > Have you looked at Doug Lea's stuff? I personally would never have a > server thread wait on anything from another thread. The idea of two > threads running together makes little sense where one is just waiting. > This may seem too strict, but I follow it to the letter. > > Jack > > > On Fri, 10 Dec 2004 08:04:12 -0700, Robert Harper <[EMAIL PROTECTED]> wrote: > > > > > > Robert S. Harper > > > > > > 801.265.8800 ex. 255 > > > -----Original Message----- > > > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > > > >I have an app that must wait for a return from another machine that > > > > > > Yikes ;( I hope you realize that fragility of this design, given that > > > J2EE apps (which includes Servlet webapps) are not supposed to create > > [Robert Harper] > > The extra thread is from the return side of the RMI link to the remote > computer. > > I do not directly spawn a thread. If you know of an event library for this > > version of the JVM, I would be happy to use that because I think things run > more > > efficient and the code looks cleaner. > > > > > > > > > > > > >The problem is that it also blocking > > > >the > > > >return thread until the loop is terminated. > > > > > > So Thread.currentThread().sleep(1000) blocks a thread other than the > > > current thread? Is the "return thread" a child of the request > > > processing thread? If so, you should make it NOT a child by > > > pre-creating it (or possibly a pool of these return threads) at app > > > startup. > > > > > > But really, you should consider an alternative design. Blocking > > > container threads is never good. > > > > > > > [Robert Harper] It looks like the blocking was due to my lack of > understanding > > of how synchronized works. I thought, wrongly, that if I added the > synchronized > > modifier to a method definition, that the method would be synchronized. It > also > > made the member data field blocking. I am used to writing Win32 > multithreaded > > apps. and I am having a hard time making the switch to the Java way of doing > > things. > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > > "You can't wake a person who is pretending to be asleep." > > ~Native Proverb~ > > "Each man is good in His sight. It is not necessary for eagles to be crows." > > ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ > > --------------------------------------------------------------------- > 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]
