You clearly need to teach A to handle unavailability of B. :-) regards Leon
On Thu, Dec 10, 2009 at 5:14 PM, Scot Hatt <sh...@radiantblue.com> wrote: > That is valid point but in my case I have no control over A. > > So I was hoping this was a commonly seen issue but I guess not so I will > expand. > > Context A contains a scheduling component that starts up a bunch of data > retrieval components that go out and grab data with the first time being > during said startup. So A calls Scheduler which then calls DR1, DR2 ... > until they all finish, then A is deployed. I know, this is not good but > workload currently foregoes refactoring. > > Order of ops: > - "http://localhost:8080/A"; starts up > - Scheduler launches > - Data retrieval component 1 fires > - Data retrieval component 2 fires > - ... > - Data retrieval component n fires and calls > "http://localhost:8080/B/servlet/HereIsData"; > - /A dies > > Does this make more sense? > -Scot > > -----Original Message----- > From: Ken Bowen [mailto:kbo...@als.com] > Sent: Thursday, December 10, 2009 10:47 AM > To: Tomcat Users List > Subject: Re: Context Chicken & Egg Problem > > If I understand you correctly, your problem is that B needs to be > initialized before A. > (I don't understand what running locally as to do with it. ??) > If that is correct, why can't you organize the initialization of A > into a trivial initial segment, > and a more substantive final segment, which contains the call to B. > When A starts, > only the trivial initial segment runs. Then use an Application > Context Listener in B, > and at the end of contextInitialized(...), make a call into A which > runs the final A segment > (which contains the call to B). > --Ken > On Dec 10, 2009, at 10:32 AM, Scot Hatt wrote: > >> Thank you for the response. >> >> I understand the limitation I am up against and it is not a >> production level >> issue that I have to get around. I have a local VM, as I stated, >> that solves >> the issue and as far as production, everything is separate. >> >> I was curious if there is a specific reference on this problem that >> I can >> point to for my fellow devs that try to run everything on a single >> Tomcat >> instance. >> >> -Scot >> >> -----Original Message----- >> From: Pid [mailto:p...@pidster.com] >> Sent: Thursday, December 10, 2009 10:22 AM >> To: users@tomcat.apache.org >> Subject: Re: Context Chicken & Egg Problem >> >> On 10/12/2009 15:15, Scot Hatt wrote: >>> Hello, >>> >>> I have spent a great deal of time scouring the bug list and trying >>> to put >>> together the right set of terms to find resolution for this but >>> have been >>> unsuccessful. >>> >>> I am dealing with a situation where webapp A is calling a servlet in >> webapp >>> B during A's startup. I think I am dealing with a chicken and egg >> situation >>> where Tomcat knows it has a B context but it can't provide access yet >>> because it is still deploying A. The symptom is a complete halt of >>> A and >>> Tomcat just sits there not responding to any requests. >>> >>> The reason for this configuration is the typical developer >>> workstation >>> situation where I need to run everything locally. It is not a show >>> stopper >>> and I have gotten around it by running a VM but that is a memory >>> hog. Is >>> there a reference to this scenario that explains why it is not >>> possible or >>> am I dealing with a known bug? >>> >>> -Scot in VA >> >> Web apps are intended to be independent. The startup sequence for >> contexts is sequential AFAIK, but the order isn't specific or >> specifiable. >> >> You have have to consider an alternative method of achieving what >> you want. >> >> >> p >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
