You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ace.apache.org by Bram Pouwelse <br...@pouwelse.com> on 2013/05/28 20:21:29 UTC
My first impression of ace
Hi,
In the last few weeks we've started using ace for a project as an attempt
to simplify the deployment procedure for one of our applications. And it
certainly has the potential to do that!
But the last few days we're doing a lot of "snapshot" releases (remove
bundle -> store -> purge from repo -> add bundle -> store).
This does the job but isn't there an easier way to replace a bundle in the
repo?
Besides that in the past 2 days ace stopped updating the target. After
removing a bundle from the artifact list and a "store" the bundle is not
removed from the target.
I've tried to fix this by: (no luck)
- Restarting the ace server
- Restarting the agent on the target
- Restarting the target (without clean)
- Restarting the target in a clean state (this resulted in a target
without bundles provisioned by ace)
What did work was removing the contents from the bundle-cache folder, but
after removing I need to define features and distributions again.
What would be the best way to find out why the target isn't updated
anymore?
This was all using the server-allinone jar built from trunk 2 weeks ago,
today I've updated to the latest version. (then again I needed to remove
the bundle-cache and my config is gome).
Thanks for creating ace!
Bram
Re: My first impression of ace
Posted by Bram Pouwelse <br...@pouwelse.com>.
Hi Marcel,
Thanks for your clarification, I'm aware of the fact that I cant update the
"core" bundles but need some starting point to be able to improve ;)
It gets even worse .... OpenJPA uses a javaagent for runtime enhancement of
the Entity classes when the classes are resolved.
For now I can live with not being able to update the core / platform
bundles and try to focus on being able to do "live" updates for my
application components.
Regards,
Bram
2013/5/29 Marcel Offermans <ma...@luminis.nl>
> Hello Bram,
>
> On May 29, 2013, at 20:38 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
>
> > I'm aware that it's a bad practice to depend on deployment / start
> > order..... But the application is using JPA for persistence to reslove
> most
> > of the start / deployment order issues I'm currently using the Karaf
> > container with and use the features to provision the "platform"
> > functionality JTA, JPA (OpenJPA) JNDI and the last feature that gets
> > installed is the ace managementagent.
>
> > After that I'm using Ace to deploy my application bundles. I'll have to
> > investigate further which bundles in my application are still picky about
> > start order ...
>
> The biggest issue with depending on startup order is not the startup
> itself (by specifying the order there, you can indeed make things work) but
> subsequent updates. Let's say you have three bundles and depend on them
> starting in order: B1 -> B2 -> B3. Now assume you have an update for B2.
> During this update it will be stopped, and the new version restarted. B3
> however, depended on B2 already being started, so chances are high that
> during the update, B3 will get confused because it does not expect B2 to
> disappear at all after it has started itself.
>
> So solving the startup problem then introduces an update problem.
>
> The only thing you can now do is the following: assign startlevels to the
> bundles and use an update process that is aware of these startlevels, as
> follows: Assume we start by giving bundle B1 startlevel 1, B2 = 2, B3 = 3.
> If we manage to assign those startlevels before starting the bundles, the
> order in which they start will be enforced by the startlevel service. That
> is good. Now what happens if we update B2. If our management agent detects
> that B2 needs updating, it can first bring the framework down to its
> startlevel, so 2 in this case, then do the update, and then go back to the
> highest startlevel again. That way, B3 is started again after B2 and will
> probably work just fine. This has two downsides:
>
> 1) If you update "core" bundles, you are practically stopping and
> restarting the whole application, which defeats the purpose of OSGi and
> performing "live" updates.
>
> 2) Bundles that assume certain startup ordering sometimes do not do proper
> cleanup when they are stopped. This is obviously not always the case, but
> I've seen bundles misbehave like that. If that happens, you'll have a tough
> time OSGi-ifying such code anyway and you might have to patch third party
> code anyway to make it behave.
>
> Further background info on startlevels in a blog article I wrote:
> http://www.planetmarrs.net/start-levels-in-osgi/
>
> Greetings, Marcel
>
>
Re: My first impression of ace
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Bram,
On May 29, 2013, at 20:38 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
> I'm aware that it's a bad practice to depend on deployment / start
> order..... But the application is using JPA for persistence to reslove most
> of the start / deployment order issues I'm currently using the Karaf
> container with and use the features to provision the "platform"
> functionality JTA, JPA (OpenJPA) JNDI and the last feature that gets
> installed is the ace managementagent.
> After that I'm using Ace to deploy my application bundles. I'll have to
> investigate further which bundles in my application are still picky about
> start order ...
The biggest issue with depending on startup order is not the startup itself (by specifying the order there, you can indeed make things work) but subsequent updates. Let's say you have three bundles and depend on them starting in order: B1 -> B2 -> B3. Now assume you have an update for B2. During this update it will be stopped, and the new version restarted. B3 however, depended on B2 already being started, so chances are high that during the update, B3 will get confused because it does not expect B2 to disappear at all after it has started itself.
So solving the startup problem then introduces an update problem.
The only thing you can now do is the following: assign startlevels to the bundles and use an update process that is aware of these startlevels, as follows: Assume we start by giving bundle B1 startlevel 1, B2 = 2, B3 = 3. If we manage to assign those startlevels before starting the bundles, the order in which they start will be enforced by the startlevel service. That is good. Now what happens if we update B2. If our management agent detects that B2 needs updating, it can first bring the framework down to its startlevel, so 2 in this case, then do the update, and then go back to the highest startlevel again. That way, B3 is started again after B2 and will probably work just fine. This has two downsides:
1) If you update "core" bundles, you are practically stopping and restarting the whole application, which defeats the purpose of OSGi and performing "live" updates.
2) Bundles that assume certain startup ordering sometimes do not do proper cleanup when they are stopped. This is obviously not always the case, but I've seen bundles misbehave like that. If that happens, you'll have a tough time OSGi-ifying such code anyway and you might have to patch third party code anyway to make it behave.
Further background info on startlevels in a blog article I wrote: http://www.planetmarrs.net/start-levels-in-osgi/
Greetings, Marcel
Re: My first impression of ace
Posted by Bram Pouwelse <br...@pouwelse.com>.
Hi Paul,
I'm aware that it's a bad practice to depend on deployment / start
order..... But the application is using JPA for persistence to reslove most
of the start / deployment order issues I'm currently using the Karaf
container with and use the features to provision the "platform"
functionality JTA, JPA (OpenJPA) JNDI and the last feature that gets
installed is the ace managementagent.
After that I'm using Ace to deploy my application bundles. I'll have to
investigate further which bundles in my application are still picky about
start order ...
Regards,
Bram
2013/5/29 Paul Bakker <pa...@luminis.eu>
> Hi Bram,
>
> It's a bad practice to depend on deployment (or start) order in OSGi. This
> means, most of the time, that service dynamics are not dealt with
> correctly. This will also cause problems when updating bundles, and because
> of that you should never rely on this. It might be difficult if it's
> framework code that causes these problems, but you should probably try to
> fix the root issue.
>
> Cheers,
>
> Paul
>
> On May 29, 2013, at 20:06 , Bram Pouwelse <br...@pouwelse.com>
> wrote:
>
> > Hi Marcel, Bram,
> >
> > @Marcel
> > Thanks for your quick and detailed reply.
> >
> > @Bram
> > I'll checkout the commandline tool and check of it can help me make
> things
> > easier.
> >
> > Today I've encountered a new problem to overcome first, ace deploys the
> > bundles in a random order and my JPA related bundles don't really like
> seem
> > to like that :(
> >
> > Regards,
> > Bram
> >
> >
> >
> >
> >
> >
> > 2013/5/29 Bram de Kruijff <bd...@gmail.com>
> >
> >> Hello Bram! :)
> >>
> >> On Tue, May 28, 2013 at 8:21 PM, Bram Pouwelse <br...@pouwelse.com>
> wrote:
> >>> Hi,
> >>>
> >>> In the last few weeks we've started using ace for a project as an
> attempt
> >>> to simplify the deployment procedure for one of our applications. And
> it
> >>> certainly has the potential to do that!
> >>> But the last few days we're doing a lot of "snapshot" releases (remove
> >>> bundle -> store -> purge from repo -> add bundle -> store).
> >>> This does the job but isn't there an easier way to replace a bundle in
> >> the
> >>> repo?
> >>
> >> I have just dropped some code [0] in my sandbox that may interest you.
> >> It is a command line tool specifically to ease and automate these
> >> tasks. It is just a first version, but it already does the basics and
> >> works on my machine ;) I would love to get some attention and feedback
> >> on this. See the README [1] for a quick impression.
> >>
> >>
> >> Regards,
> >> your namesake
> >>
> >> [0] http://svn.apache.org/viewvc?view=revision&revision=r1487431
> >> [1]
> >>
> http://svn.apache.org/viewvc/ace/sandbox/bramk/org.apache.ace.cli/README.md?view=markup&pathrev=1487431
> >>
> >>>
> >>> Besides that in the past 2 days ace stopped updating the target. After
> >>> removing a bundle from the artifact list and a "store" the bundle is
> not
> >>> removed from the target.
> >>>
> >>> I've tried to fix this by: (no luck)
> >>> - Restarting the ace server
> >>> - Restarting the agent on the target
> >>> - Restarting the target (without clean)
> >>> - Restarting the target in a clean state (this resulted in a target
> >>> without bundles provisioned by ace)
> >>>
> >>> What did work was removing the contents from the bundle-cache folder,
> but
> >>> after removing I need to define features and distributions again.
> >>>
> >>> What would be the best way to find out why the target isn't updated
> >>> anymore?
> >>>
> >>> This was all using the server-allinone jar built from trunk 2 weeks
> ago,
> >>> today I've updated to the latest version. (then again I needed to
> remove
> >>> the bundle-cache and my config is gome).
> >>>
> >>>
> >>> Thanks for creating ace!
> >>>
> >>> Bram
> >>
>
>
Re: My first impression of ace
Posted by Paul Bakker <pa...@luminis.eu>.
Hi Bram,
It's a bad practice to depend on deployment (or start) order in OSGi. This means, most of the time, that service dynamics are not dealt with correctly. This will also cause problems when updating bundles, and because of that you should never rely on this. It might be difficult if it's framework code that causes these problems, but you should probably try to fix the root issue.
Cheers,
Paul
On May 29, 2013, at 20:06 , Bram Pouwelse <br...@pouwelse.com>
wrote:
> Hi Marcel, Bram,
>
> @Marcel
> Thanks for your quick and detailed reply.
>
> @Bram
> I'll checkout the commandline tool and check of it can help me make things
> easier.
>
> Today I've encountered a new problem to overcome first, ace deploys the
> bundles in a random order and my JPA related bundles don't really like seem
> to like that :(
>
> Regards,
> Bram
>
>
>
>
>
>
> 2013/5/29 Bram de Kruijff <bd...@gmail.com>
>
>> Hello Bram! :)
>>
>> On Tue, May 28, 2013 at 8:21 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
>>> Hi,
>>>
>>> In the last few weeks we've started using ace for a project as an attempt
>>> to simplify the deployment procedure for one of our applications. And it
>>> certainly has the potential to do that!
>>> But the last few days we're doing a lot of "snapshot" releases (remove
>>> bundle -> store -> purge from repo -> add bundle -> store).
>>> This does the job but isn't there an easier way to replace a bundle in
>> the
>>> repo?
>>
>> I have just dropped some code [0] in my sandbox that may interest you.
>> It is a command line tool specifically to ease and automate these
>> tasks. It is just a first version, but it already does the basics and
>> works on my machine ;) I would love to get some attention and feedback
>> on this. See the README [1] for a quick impression.
>>
>>
>> Regards,
>> your namesake
>>
>> [0] http://svn.apache.org/viewvc?view=revision&revision=r1487431
>> [1]
>> http://svn.apache.org/viewvc/ace/sandbox/bramk/org.apache.ace.cli/README.md?view=markup&pathrev=1487431
>>
>>>
>>> Besides that in the past 2 days ace stopped updating the target. After
>>> removing a bundle from the artifact list and a "store" the bundle is not
>>> removed from the target.
>>>
>>> I've tried to fix this by: (no luck)
>>> - Restarting the ace server
>>> - Restarting the agent on the target
>>> - Restarting the target (without clean)
>>> - Restarting the target in a clean state (this resulted in a target
>>> without bundles provisioned by ace)
>>>
>>> What did work was removing the contents from the bundle-cache folder, but
>>> after removing I need to define features and distributions again.
>>>
>>> What would be the best way to find out why the target isn't updated
>>> anymore?
>>>
>>> This was all using the server-allinone jar built from trunk 2 weeks ago,
>>> today I've updated to the latest version. (then again I needed to remove
>>> the bundle-cache and my config is gome).
>>>
>>>
>>> Thanks for creating ace!
>>>
>>> Bram
>>
Re: My first impression of ace
Posted by Bram Pouwelse <br...@pouwelse.com>.
Hi Marcel, Bram,
@Marcel
Thanks for your quick and detailed reply.
@Bram
I'll checkout the commandline tool and check of it can help me make things
easier.
Today I've encountered a new problem to overcome first, ace deploys the
bundles in a random order and my JPA related bundles don't really like seem
to like that :(
Regards,
Bram
2013/5/29 Bram de Kruijff <bd...@gmail.com>
> Hello Bram! :)
>
> On Tue, May 28, 2013 at 8:21 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
> > Hi,
> >
> > In the last few weeks we've started using ace for a project as an attempt
> > to simplify the deployment procedure for one of our applications. And it
> > certainly has the potential to do that!
> > But the last few days we're doing a lot of "snapshot" releases (remove
> > bundle -> store -> purge from repo -> add bundle -> store).
> > This does the job but isn't there an easier way to replace a bundle in
> the
> > repo?
>
> I have just dropped some code [0] in my sandbox that may interest you.
> It is a command line tool specifically to ease and automate these
> tasks. It is just a first version, but it already does the basics and
> works on my machine ;) I would love to get some attention and feedback
> on this. See the README [1] for a quick impression.
>
>
> Regards,
> your namesake
>
> [0] http://svn.apache.org/viewvc?view=revision&revision=r1487431
> [1]
> http://svn.apache.org/viewvc/ace/sandbox/bramk/org.apache.ace.cli/README.md?view=markup&pathrev=1487431
>
> >
> > Besides that in the past 2 days ace stopped updating the target. After
> > removing a bundle from the artifact list and a "store" the bundle is not
> > removed from the target.
> >
> > I've tried to fix this by: (no luck)
> > - Restarting the ace server
> > - Restarting the agent on the target
> > - Restarting the target (without clean)
> > - Restarting the target in a clean state (this resulted in a target
> > without bundles provisioned by ace)
> >
> > What did work was removing the contents from the bundle-cache folder, but
> > after removing I need to define features and distributions again.
> >
> > What would be the best way to find out why the target isn't updated
> > anymore?
> >
> > This was all using the server-allinone jar built from trunk 2 weeks ago,
> > today I've updated to the latest version. (then again I needed to remove
> > the bundle-cache and my config is gome).
> >
> >
> > Thanks for creating ace!
> >
> > Bram
>
Re: My first impression of ace
Posted by Bram de Kruijff <bd...@gmail.com>.
Hello Bram! :)
On Tue, May 28, 2013 at 8:21 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
> Hi,
>
> In the last few weeks we've started using ace for a project as an attempt
> to simplify the deployment procedure for one of our applications. And it
> certainly has the potential to do that!
> But the last few days we're doing a lot of "snapshot" releases (remove
> bundle -> store -> purge from repo -> add bundle -> store).
> This does the job but isn't there an easier way to replace a bundle in the
> repo?
I have just dropped some code [0] in my sandbox that may interest you.
It is a command line tool specifically to ease and automate these
tasks. It is just a first version, but it already does the basics and
works on my machine ;) I would love to get some attention and feedback
on this. See the README [1] for a quick impression.
Regards,
your namesake
[0] http://svn.apache.org/viewvc?view=revision&revision=r1487431
[1] http://svn.apache.org/viewvc/ace/sandbox/bramk/org.apache.ace.cli/README.md?view=markup&pathrev=1487431
>
> Besides that in the past 2 days ace stopped updating the target. After
> removing a bundle from the artifact list and a "store" the bundle is not
> removed from the target.
>
> I've tried to fix this by: (no luck)
> - Restarting the ace server
> - Restarting the agent on the target
> - Restarting the target (without clean)
> - Restarting the target in a clean state (this resulted in a target
> without bundles provisioned by ace)
>
> What did work was removing the contents from the bundle-cache folder, but
> after removing I need to define features and distributions again.
>
> What would be the best way to find out why the target isn't updated
> anymore?
>
> This was all using the server-allinone jar built from trunk 2 weeks ago,
> today I've updated to the latest version. (then again I needed to remove
> the bundle-cache and my config is gome).
>
>
> Thanks for creating ace!
>
> Bram
Re: My first impression of ace
Posted by Marcel Offermans <ma...@luminis.nl>.
Hello Bram,
On May 28, 2013, at 20:21 PM, Bram Pouwelse <br...@pouwelse.com> wrote:
> In the last few weeks we've started using ace for a project as an attempt
> to simplify the deployment procedure for one of our applications. And it
> certainly has the potential to do that!
> But the last few days we're doing a lot of "snapshot" releases (remove
> bundle -> store -> purge from repo -> add bundle -> store).
> This does the job but isn't there an easier way to replace a bundle in the
> repo?
We usually take a different approach. In stead of calling everything "1.0.0.SNAPSHOT" we usually use that last part (the qualifier) to encode a timestamp, so something like "1.0.0.20130528212600". In Bnd there is a macro you can use to achieve that:
Bundle-Version: 1.0.5.${tstamp}
ACE assumes that the combination of bundle symbolic name + bundle version is unique, so by design it does not detect changes if the version remains the same.
The trick you use, does work, and there is no easier version (you can automate the process a bit more though, by talking to the REST client API from some kind of script (or build task).
> Besides that in the past 2 days ace stopped updating the target. After
> removing a bundle from the artifact list and a "store" the bundle is not
> removed from the target.
>
> I've tried to fix this by: (no luck)
> - Restarting the ace server
> - Restarting the agent on the target
> - Restarting the target (without clean)
> - Restarting the target in a clean state (this resulted in a target
> without bundles provisioned by ace)
>
> What did work was removing the contents from the bundle-cache folder, but
> after removing I need to define features and distributions again.
Just to make sure, after clearing out the cache, you configured exactly the same set of bundles to be deployed to the target?
In theory there are a couple of reasons why a deployment fails (these are defined in the Deployment Admin specification) but if you deploy a set of bundles they should consistently work. So you might actually have stumbled on a bug. Hard to tell without more data.
If this happens again, please save a copy of the bundle cache (and store). You can send it to me off-list so I can take a look.
> What would be the best way to find out why the target isn't updated
> anymore?
I usually do a couple of things (let's say I have a target called target-1):
1) I validate (with a REST client or within the browser) that I indeed get the correct list of available versions: http://localhost:8080/deployment/target-1/versions
2) I manually download the deployment package with the highest version (let's say it was 5.0.0):
http://localhost:8080/deployment/target-1/versions/5.0.0 (a deployment package is a jar, and you can inspect it to see all the artifacts you expect are actually in there)
3) If that looks good, I usually try to add a shell to the target, so I can interact with it (you can also deploy the Felix WebConsole if you like that better). This allows me to inspect the target in more detail, and also view the log on the target. I then usually start by just deploying the shell, and then, as a second step, deploy the other artifacts.
> This was all using the server-allinone jar built from trunk 2 weeks ago,
> today I've updated to the latest version. (then again I needed to remove
> the bundle-cache and my config is gome).
Yes, one of the things we did was change the storage format for the internal repositories. We now compress them on disk, which saves a lot of disk space.
> Thanks for creating ace!
Thanks for your feedback. Let us know if we can help you narrow down the problems you had.
Greetings, Marcel