You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Scot Hatt <sh...@radiantblue.com> on 2009/12/10 16:15:09 UTC
Context Chicken & Egg Problem
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
Re: Context Chicken & Egg Problem
Posted by Pid <pi...@pidster.com>.
On 10/12/2009 15:22, Pid wrote:
> 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.
s/have have/may have/
p
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scot,
On 12/10/2009 10:32 AM, Scot Hatt wrote:
> 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.
Not on a single Tomcat instance, but you could always run multiple
Tomcat instances.
Or, make your webapp more tolerant of a missing sister-app. Instead of
trying to access webapp B from webapp A's startup, why not do some lazy
initialization and wait until webapp B's access is actually required?
That would allow you to start up the webapps in any order, but you
wouldn't be able to use some set of features until webapp B was actually
available.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkshgBYACgkQ9CaO5/Lv0PCf4wCfW16al+m3kCNA5U4sxRXpQBUj
DXYAn3s5b4WLpO8GeshblAM/wM5W9nS9
=z3t5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Chicken & Egg Problem
Posted by Scot Hatt <sh...@radiantblue.com>.
You are all correct.
So, I wasn't necessarily looking for a code solution. The system works
perfectly fine in the tiered production environment. I was, however, looking
for a case as to why an HTTP request should "not" be made to another context
in the same container during initialization.
I figured things like this happen when you are trying to run the entire
enterprise on a development machine.
Sharing a container for apps that, in production, are performing external
HTTP Request/Response "during initialization" and are now trying to perform
that communication, essentially on a loopback, to peer contexts, seems like
it would be a no-no.
So I will just end this discussion and give a warm thank you to all who
participated.
-Scot
-----Original Message-----
From: Ken Bowen [mailto:kbowen@als.com]
Sent: Thursday, December 10, 2009 1:04 PM
To: Tomcat Users List
Subject: Re: Context Chicken & Egg Problem
It still seems like a simple issue to me.
Split your initialization of A into A1 and A2.
A2 is no longer part of immediate initialization for A.
Put your Scheduler launches, with their Data retrieve components, into
A2.
When A is started, it will only run A1.
When B is started, at the end of it's
ServletContextListener.contextinitialized(...),
it makes a call into A which causes A to run A2. Then when your
retrieval
components call into B, it is ready for them.
--Ken
On Dec 10, 2009, at 11:14 AM, Scot Hatt 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:kbowen@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:pid@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Ken Bowen <kb...@als.com>.
It still seems like a simple issue to me.
Split your initialization of A into A1 and A2.
A2 is no longer part of immediate initialization for A.
Put your Scheduler launches, with their Data retrieve components, into
A2.
When A is started, it will only run A1.
When B is started, at the end of it's
ServletContextListener.contextinitialized(...),
it makes a call into A which causes A to run A2. Then when your
retrieval
components call into B, it is ready for them.
--Ken
On Dec 10, 2009, at 11:14 AM, Scot Hatt 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:kbowen@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:pid@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Leon Rosenberg <ro...@googlemail.com>.
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:kbowen@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:pid@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Chicken & Egg Problem
Posted by Scot Hatt <sh...@radiantblue.com>.
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:kbowen@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:pid@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Ken Bowen <kb...@als.com>.
And it's not even Monday:
Application Context Listener = ServletContextListener
On Dec 10, 2009, at 10:46 AM, Ken Bowen wrote:
> 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:pid@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Ken Bowen <kb...@als.com>.
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:pid@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scot,
On 12/10/2009 12:45 PM, Scot Hatt wrote:
> So either I am just not able to adequately describe what I am seeing, nobody
> has dealt with this issue, or I am completely missing the forest through the
> trees via the information you are providing.
I responded earlier before I read that you cannot change webapp A.
In that case, would a second Tomcat instance be a possibility? If so,
see the "Advanced" section of the RUNNING.txt file that is bundled with
Tomcat: it will show you how to run multiple instances of Tomcat. That's
certainly much better than running an entire virtual machine just to run
another instance of Tomcat :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkshgMQACgkQ9CaO5/Lv0PA7FgCfXT4phaRNdI05DidiI7qY93y/
nDAAn1tYzQ6SxX3zoRsMv/oX/CWpWJ15
=j2LT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Chicken & Egg Problem
Posted by Scot Hatt <sh...@radiantblue.com>.
True, I did ask for a reference, for the specific issue of http requests out
of a webapp to another webapp in the same container "during initialization,"
causing a halt condition.
So either I am just not able to adequately describe what I am seeing, nobody
has dealt with this issue, or I am completely missing the forest through the
trees via the information you are providing.
-Scot
-----Original Message-----
From: Pid [mailto:pid@pidster.com]
Sent: Thursday, December 10, 2009 11:26 AM
To: Tomcat Users List
Subject: Re: Context Chicken & Egg Problem
On 10/12/2009 16:14, Scot Hatt wrote:
> So you are saying that a normally available Servlet interface that is
> implemented correctly and functions properly in production mode has
> something to do with Tomcat contexts being available during a peer
context's
> deployment?
That's a heck of an extrapolation.
You asked about a reference, the Servlet Spec is the best one. I've
found it helpful when I couldn't get Tomcat to behave how I wanted it to.
p
> -Scot
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Thursday, December 10, 2009 10:52 AM
> To: Scot Hatt
> Subject: Re: Context Chicken& Egg Problem
>
> On 10/12/2009 15:32, 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.
>
> The Servlet Spec? The popular refrain here is that "it's surprisingly
> readable".
>
>
> p
>
>
>> -Scot
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Pid <pi...@pidster.com>.
On 10/12/2009 16:14, Scot Hatt wrote:
> So you are saying that a normally available Servlet interface that is
> implemented correctly and functions properly in production mode has
> something to do with Tomcat contexts being available during a peer context's
> deployment?
That's a heck of an extrapolation.
You asked about a reference, the Servlet Spec is the best one. I've
found it helpful when I couldn't get Tomcat to behave how I wanted it to.
p
> -Scot
>
> -----Original Message-----
> From: Pid [mailto:pid@pidster.com]
> Sent: Thursday, December 10, 2009 10:52 AM
> To: Scot Hatt
> Subject: Re: Context Chicken& Egg Problem
>
> On 10/12/2009 15:32, 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.
>
> The Servlet Spec? The popular refrain here is that "it's surprisingly
> readable".
>
>
> p
>
>
>> -Scot
>>
>> -----Original Message-----
>> From: Pid [mailto:pid@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Chicken & Egg Problem
Posted by Scot Hatt <sh...@radiantblue.com>.
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:pid@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Chicken & Egg Problem
Posted by Pid <pi...@pidster.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org