You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Kevan Miller <ke...@gmail.com> on 2005/11/22 05:24:02 UTC
undeploy behavior
I've started taking a look at problems we have deleting config-store
directories during undeploy. As I've been looking at the problem, I've
encountered a few surprises. I'm wondering how we expect users to know what
modules they should be undeploying. Do we have a precise description of how
users should go about understanding what happens during a deploy and how the
effects of a deploy can be undone?
As an example, a deploy of DayTrader will create the following
modules/config-store directories:
1) Trade (configid of application defined in daytrader-plan.xml)
2) tradeStreamerAppClient (clientConfigId of an application-client defined
in daytrader-plan.xml)
3) Trade/daytrader-wsappclient-1.0-SNAPSHOT (dynamic GBean for web services?
it's not in the daytrader plan).
I was naively attempting to undeploy DayTrader with an 'java -jar
deployer.jar undeploy Trade'. However, it seems that this will only deal
with the 'Trade' module, not the other two modules. Is this as intended? Or
is there a basic bug?
It's a bit confusing because a subsequent redeploy of DayTrader will work.
New tradeStreamerAppclient and wsappclient modules/config store directories
will be created (however the old config-store directories will not be
deleted).
So, in order to properly undeploy "DayTrader", I must know the configids of
the application(s), application-client(s), and any dynamically generated
resource(s) which have been mapped to a module. Each module must be
specifically deleted (i.e. undeployed). Is all of this correct? Seems like a
non-intuitive task, to me... Is all of this described somewhere?
FYI, I rarely see the config-store directories being properly deleted after
undeploying the DayTrader modules. We're almost never able to delete the jar
files in the Trade config-store directory. I assume (as others have
surmised) that there is a Classloader hanging around with file descriptors
open to the jar files.. I'm working to get a handle on the problem...
--kevan
Re: undeploy behavior
Posted by David Jencks <da...@yahoo.com>.
On Nov 21, 2005, at 9:41 PM, Kevan Miller wrote:
>
> On 11/22/05, Kevan Miller <ke...@gmail.com> wrote:
>> On 11/22/05, Aaron Mulder < ammulder@alumni.princeton.edu> wrote:
>>> deployment... but I never work with app clients much either. I don't
>>> like the sound of the behavior you're describing as it means that
>>> redeploy can't really work as intended (where you give it a configId
>>> and it replaces it). Are there instructions for building the trade
>>> application somewhere, so I can try this out for myself?
>> DayTrader is in sandbox/daytrader. There's a README which is
>> accurate. Should be something like:
>>
>> cd sandbox/daytrader
>> maven
>> <start the server>
>> set GERONIMO_HOME env variable
>> derby/createDB.sh
>> deploy modules/ear/target/daytrader-ear-1.0-SNAPSHOT.ear
>> daytrader-plan.xml
>>
>> I think I had a problem with ActiveMQ dependencies, but that may
>> have been because I've been running with a private ActiveMQ build to
>> pick up a fix...
> Forgot to mention, I get multiple warnings during deploy as follows:
>
> 23:42:19,140 WARN [HeavyweightTypeInfoBuilder] No soap array info
> for schematype:
> T=ArrayOfQuoteDataBean@http://daytrader.samples.geronimo.apache.org
>
> I've been ignoring, but something that needs to be sorted out. I
> haven't investigated. Assume it's something that Matt will be looking
> into...
This is just warning you that your jaxrpc type mapping is not portable,
but we are guessing what you want. To gauge the severity of the
problem, AFAICT no one, including Sun, has ever succeeded in writing a
portable jaxrpc type mapping for a non-trivial soap message.
thanks
david jencks
>
>>>
>>> end of the deploy operation. If we don't list all the modules we
>>> created, that's a bug.
>>>
>>> As for the file locking, I think that's a pretty well-established
>>> side
>>> effect of Sun's URLClassLoader on Windows. I wonder, if we mark
>>> those
>>> files to be deleted on exit, would it work?
>> The files are marked to be deleted on exit. However, in the past,
>> the files weren't deleted. I haven't checked this recently.
>>
>> --kevan
>>
>>> Thanks,
>>> Aaron
>>>
>>> On 11/21/05, Kevan Miller < kevan.miller@gmail.com> wrote:
>>> > I've started taking a look at problems we have deleting
>>> config-store
>>> > directories during undeploy. As I've been looking at the problem,
>>> I've
>>> > encountered a few surprises. I'm wondering how we expect users to
>>> know what
>>> > modules they should be undeploying. Do we have a precise
>>> description of how
>>> > users should go about understanding what happens during a deploy
>>> and how the
>>> > effects of a deploy can be undone?
>>> >
>>> > As an example, a deploy of DayTrader will create the following
>>> > modules/config-store directories:
>>> >
>>> > 1) Trade (configid of application defined in daytrader-plan.xml)
>>> > 2) tradeStreamerAppClient (clientConfigId of an
>>> application-client defined
>>> > in daytrader-plan.xml)
>>> > 3) Trade/daytrader-wsappclient-1.0-SNAPSHOT (dynamic GBean for web
>>> > services? it's not in the daytrader plan).
>>> >
>>> > I was naively attempting to undeploy DayTrader with an 'java -jar
>>> > deployer.jar undeploy Trade'. However, it seems that this will
>>> only deal
>>> > with the 'Trade' module, not the other two modules. Is this as
>>> intended? Or
>>> > is there a basic bug?
>>> >
>>> > It's a bit confusing because a subsequent redeploy of DayTrader
>>> will work.
>>> > New tradeStreamerAppclient and wsappclient modules/config store
>>> directories
>>> > will be created (however the old config-store directories will not
>>> be
>>> > deleted).
>>> >
>>> > So, in order to properly undeploy "DayTrader", I must know the
>>> configids of
>>> > the application(s), application-client(s), and any dynamically
>>> generated
>>> > resource(s) which have been mapped to a module. Each module must be
>>> > specifically deleted (i.e. undeployed). Is all of this correct?
>>> Seems like a
>>> > non-intuitive task, to me... Is all of this described somewhere?
>>> >
>>> > FYI, I rarely see the config-store directories being properly
>>> deleted after
>>> > undeploying the DayTrader modules. We're almost never able to
>>> delete the jar
>>> > files in the Trade config-store directory. I assume (as others have
>>> > surmised) that there is a Classloader hanging around with file
>>> descriptors
>>> > open to the jar files.. I'm working to get a handle on the
>>> problem...
>>> >
>>> > --kevan
>>> >
>>> >
>>> >
>>
Re: undeploy behavior
Posted by Kevan Miller <ke...@gmail.com>.
On 11/22/05, Kevan Miller <ke...@gmail.com> wrote:
>
>
> On 11/22/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> >
> > I haven't seen a case where we create more than one module during a
> > deployment... but I never work with app clients much either. I don't
> > like the sound of the behavior you're describing as it means that
> > redeploy can't really work as intended (where you give it a configId
> > and it replaces it). Are there instructions for building the trade
> > application somewhere, so I can try this out for myself?
>
>
> DayTrader is in sandbox/daytrader. There's a README which is accurate.
> Should be something like:
>
> cd sandbox/daytrader
> maven
> <start the server>
> set GERONIMO_HOME env variable
> derby/createDB.sh
> deploy modules/ear/target/daytrader-ear-1.0-SNAPSHOT.ear
> daytrader-plan.xml
>
> I think I had a problem with ActiveMQ dependencies, but that may have been
> because I've been running with a private ActiveMQ build to pick up a fix...
>
Forgot to mention, I get multiple warnings during deploy as follows:
23:42:19,140 WARN [HeavyweightTypeInfoBuilder] No soap array info for
schematype: T=ArrayOfQuoteDataBean@
http://daytrader.samples.geronimo.apache.org
I've been ignoring, but something that needs to be sorted out. I haven't
investigated. Assume it's something that Matt will be looking into...
In any case, we should be giving the user a list of configIds at the
> > end of the deploy operation. If we don't list all the modules we
> > created, that's a bug.
> >
> > As for the file locking, I think that's a pretty well-established side
> > effect of Sun's URLClassLoader on Windows. I wonder, if we mark those
> > files to be deleted on exit, would it work?
>
>
> The files are marked to be deleted on exit. However, in the past, the
> files weren't deleted. I haven't checked this recently.
>
> --kevan
>
> Thanks,
> > Aaron
> >
> > On 11/21/05, Kevan Miller < kevan.miller@gmail.com> wrote:
> > > I've started taking a look at problems we have deleting config-store
> > > directories during undeploy. As I've been looking at the problem, I've
> > > encountered a few surprises. I'm wondering how we expect users to know
> > what
> > > modules they should be undeploying. Do we have a precise description
> > of how
> > > users should go about understanding what happens during a deploy and
> > how the
> > > effects of a deploy can be undone?
> > >
> > > As an example, a deploy of DayTrader will create the following
> > > modules/config-store directories:
> > >
> > > 1) Trade (configid of application defined in daytrader-plan.xml)
> > > 2) tradeStreamerAppClient (clientConfigId of an application-client
> > defined
> > > in daytrader-plan.xml)
> > > 3) Trade/daytrader-wsappclient-1.0-SNAPSHOT (dynamic GBean for web
> > > services? it's not in the daytrader plan).
> > >
> > > I was naively attempting to undeploy DayTrader with an 'java -jar
> > > deployer.jar undeploy Trade'. However, it seems that this will only
> > deal
> > > with the 'Trade' module, not the other two modules. Is this as
> > intended? Or
> > > is there a basic bug?
> > >
> > > It's a bit confusing because a subsequent redeploy of DayTrader will
> > work.
> > > New tradeStreamerAppclient and wsappclient modules/config store
> > directories
> > > will be created (however the old config-store directories will not be
> > > deleted).
> > >
> > > So, in order to properly undeploy "DayTrader", I must know the
> > configids of
> > > the application(s), application-client(s), and any dynamically
> > generated
> > > resource(s) which have been mapped to a module. Each module must be
> > > specifically deleted (i.e. undeployed). Is all of this correct? Seems
> > like a
> > > non-intuitive task, to me... Is all of this described somewhere?
> > >
> > > FYI, I rarely see the config-store directories being properly deleted
> > after
> > > undeploying the DayTrader modules. We're almost never able to delete
> > the jar
> > > files in the Trade config-store directory. I assume (as others have
> > > surmised) that there is a Classloader hanging around with file
> > descriptors
> > > open to the jar files.. I'm working to get a handle on the problem...
> > >
> > > --kevan
> > >
> > >
> > >
> >
>
>
Re: undeploy behavior
Posted by Kevan Miller <ke...@gmail.com>.
On 11/22/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
> I haven't seen a case where we create more than one module during a
> deployment... but I never work with app clients much either. I don't
> like the sound of the behavior you're describing as it means that
> redeploy can't really work as intended (where you give it a configId
> and it replaces it). Are there instructions for building the trade
> application somewhere, so I can try this out for myself?
DayTrader is in sandbox/daytrader. There's a README which is accurate.
Should be something like:
cd sandbox/daytrader
maven
<start the server>
set GERONIMO_HOME env variable
derby/createDB.sh
deploy modules/ear/target/daytrader-ear-1.0-SNAPSHOT.ear daytrader-plan.xml
I think I had a problem with ActiveMQ dependencies, but that may have been
because I've been running with a private ActiveMQ build to pick up a fix...
In any case, we should be giving the user a list of configIds at the
> end of the deploy operation. If we don't list all the modules we
> created, that's a bug.
>
> As for the file locking, I think that's a pretty well-established side
> effect of Sun's URLClassLoader on Windows. I wonder, if we mark those
> files to be deleted on exit, would it work?
The files are marked to be deleted on exit. However, in the past, the files
weren't deleted. I haven't checked this recently.
--kevan
Thanks,
> Aaron
>
> On 11/21/05, Kevan Miller <ke...@gmail.com> wrote:
> > I've started taking a look at problems we have deleting config-store
> > directories during undeploy. As I've been looking at the problem, I've
> > encountered a few surprises. I'm wondering how we expect users to know
> what
> > modules they should be undeploying. Do we have a precise description of
> how
> > users should go about understanding what happens during a deploy and how
> the
> > effects of a deploy can be undone?
> >
> > As an example, a deploy of DayTrader will create the following
> > modules/config-store directories:
> >
> > 1) Trade (configid of application defined in daytrader-plan.xml)
> > 2) tradeStreamerAppClient (clientConfigId of an application-client
> defined
> > in daytrader-plan.xml)
> > 3) Trade/daytrader-wsappclient-1.0-SNAPSHOT (dynamic GBean for web
> > services? it's not in the daytrader plan).
> >
> > I was naively attempting to undeploy DayTrader with an 'java -jar
> > deployer.jar undeploy Trade'. However, it seems that this will only deal
> > with the 'Trade' module, not the other two modules. Is this as intended?
> Or
> > is there a basic bug?
> >
> > It's a bit confusing because a subsequent redeploy of DayTrader will
> work.
> > New tradeStreamerAppclient and wsappclient modules/config store
> directories
> > will be created (however the old config-store directories will not be
> > deleted).
> >
> > So, in order to properly undeploy "DayTrader", I must know the configids
> of
> > the application(s), application-client(s), and any dynamically generated
> > resource(s) which have been mapped to a module. Each module must be
> > specifically deleted (i.e. undeployed). Is all of this correct? Seems
> like a
> > non-intuitive task, to me... Is all of this described somewhere?
> >
> > FYI, I rarely see the config-store directories being properly deleted
> after
> > undeploying the DayTrader modules. We're almost never able to delete the
> jar
> > files in the Trade config-store directory. I assume (as others have
> > surmised) that there is a Classloader hanging around with file
> descriptors
> > open to the jar files.. I'm working to get a handle on the problem...
> >
> > --kevan
> >
> >
> >
>
Re: undeploy behavior
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I haven't seen a case where we create more than one module during a
deployment... but I never work with app clients much either. I don't
like the sound of the behavior you're describing as it means that
redeploy can't really work as intended (where you give it a configId
and it replaces it). Are there instructions for building the trade
application somewhere, so I can try this out for myself?
In any case, we should be giving the user a list of configIds at the
end of the deploy operation. If we don't list all the modules we
created, that's a bug.
As for the file locking, I think that's a pretty well-established side
effect of Sun's URLClassLoader on Windows. I wonder, if we mark those
files to be deleted on exit, would it work?
Thanks,
Aaron
On 11/21/05, Kevan Miller <ke...@gmail.com> wrote:
> I've started taking a look at problems we have deleting config-store
> directories during undeploy. As I've been looking at the problem, I've
> encountered a few surprises. I'm wondering how we expect users to know what
> modules they should be undeploying. Do we have a precise description of how
> users should go about understanding what happens during a deploy and how the
> effects of a deploy can be undone?
>
> As an example, a deploy of DayTrader will create the following
> modules/config-store directories:
>
> 1) Trade (configid of application defined in daytrader-plan.xml)
> 2) tradeStreamerAppClient (clientConfigId of an application-client defined
> in daytrader-plan.xml)
> 3) Trade/daytrader-wsappclient-1.0-SNAPSHOT (dynamic GBean for web
> services? it's not in the daytrader plan).
>
> I was naively attempting to undeploy DayTrader with an 'java -jar
> deployer.jar undeploy Trade'. However, it seems that this will only deal
> with the 'Trade' module, not the other two modules. Is this as intended? Or
> is there a basic bug?
>
> It's a bit confusing because a subsequent redeploy of DayTrader will work.
> New tradeStreamerAppclient and wsappclient modules/config store directories
> will be created (however the old config-store directories will not be
> deleted).
>
> So, in order to properly undeploy "DayTrader", I must know the configids of
> the application(s), application-client(s), and any dynamically generated
> resource(s) which have been mapped to a module. Each module must be
> specifically deleted (i.e. undeployed). Is all of this correct? Seems like a
> non-intuitive task, to me... Is all of this described somewhere?
>
> FYI, I rarely see the config-store directories being properly deleted after
> undeploying the DayTrader modules. We're almost never able to delete the jar
> files in the Trade config-store directory. I assume (as others have
> surmised) that there is a Classloader hanging around with file descriptors
> open to the jar files.. I'm working to get a handle on the problem...
>
> --kevan
>
>
>