ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthijs Hendriks (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (ACE-269) Target no longer resolves after randomly adding/removing bundles.
Date Tue, 22 May 2012 14:47:42 GMT

    [ https://issues.apache.org/jira/browse/ACE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281006#comment-13281006
] 

Matthijs Hendriks edited comment on ACE-269 at 5/22/12 2:47 PM:
----------------------------------------------------------------

I got similar problems using the Amdatu management server. With the following bundles upload:

 * org.osgi:org.osgi.compendium
 * org.apache.felix:org.apache.felix.dependencymanager
 * org.apache.felix:org.apache.felix.dependencymanager.shell
 * org.apache.felix:org.apache.felix.metatype
 * org.apache.felix:org.apache.felix.log
 * org.apache.felix:org.apache.felix.shell
 * org.apache.felix:org.apache.felix.shell.tui
 * org.amdatu.tenant:org.amdatu.tenant.api
 * org.amdatu.tenant:org.amdatu.tenant.adapter
 * org.amdatu.tenant:org.amdatu.tenant.factory
 * org.amdatu.tenant:org.amdatu.tenant.conf.rp
 * org.amdatu.deployment:org.amdatu.deployment.autoconf
 * org.amdatu.eventadmin:org.amdatu.multitenant.org.apache.felix.eventadmin
 * org.amdatu.preferences:org.amdatu.multitenant.org.apache.felix.prefs
 * org.amdatu.useradmin:org.amdatu.multitenant.org.ops4j.pax.useradmin.pax-useradmin-service
 * org.amdatu.useradmin:org.amdatu.multitenant.org.amdatu.useradmin.pax.fsstorage
 * org.amdatu.web:org.amdatu.web.dispatcher
 * org.amdatu.web:org.amdatu.web.httpcontext
 * org.amdatu.httpservice:org.amdatu.multitenant.org.apache.felix.http.jetty
 * org.amdatu.web:org.amdatu.web.jaxrs
 * org.amdatu.web:org.amdatu.web.tenantresolver.hostname
 * org.amdatu.web:org.amdatu.web.tenantresolver.parameter
 * org.amdatu.web:org.amdatu.web.wink
 * org.amdatu.kitchensink:org.amdatu.kitchensink.demo.tenant.global
 * org.amdatu.kitchensink:org.amdatu.kitchensink.demo.tenant.local
 * org.amdatu.kitchensink:org.amdatu.kitchensink.demo.tenant.web
I used the config files in the kitchensink (release-server/src/main/resources/config/demo-multitenant).
The versions of the Amdatu bundles is 1.0.0-SNAPSHOT.

When I randomly add/remove bundles, things break. I haven't been able to construct a step-by-step
'manual' to reproduce it, but there are some things that I found remarkable.
 * The problem seems to be something with the config files (by which I mean the .xml files
and not the .tenant files);
 * if you provision the config files one by one, it usually doesn't break, although it does
happen sometimes;
 * if you provision multiple config files at once, it usually breaks;
 * if you managed to provision several config files, shutdown the agent, clean its cache and
restart it, it always breaks (well, it did for me);
 * after it broke, you won't be able to always fix it, since the target seems to 'freeze'.
You can still add/remove bundles, provision them, etc, but the provisioning state remains
'Failed', whatever you do. However, the available version etc, does change. The only 'fix'
is a restart with clean cache.
 * Even if you manage to provision the config files, they're ignored.
Note: by 'breaking' I mean that the provisioning fails, the state being 'Failed'.

Neither the server, nor the agent seems to log anything useful for this, so unfortunately,
I've got no logs on this bug.

This might be Amdatu specific, I'm not sure...
                
      was (Author: matthijsh):
    I got similar problems using the Amdatu management server. With the following bundles
upload:

 * org.osgi:org.osgi.compendium
 * org.apache.felix:org.apache.felix.dependencymanager
 * org.apache.felix:org.apache.felix.dependencymanager.shell
 * org.apache.felix:org.apache.felix.metatype
 * org.apache.felix:org.apache.felix.log
 * org.apache.felix:org.apache.felix.shell
 * org.apache.felix:org.apache.felix.shell.tui
 * org.amdatu.tenant:org.amdatu.tenant.api
 * org.amdatu.tenant:org.amdatu.tenant.adapter
 * org.amdatu.tenant:org.amdatu.tenant.factory
 * org.amdatu.tenant:org.amdatu.tenant.conf.rp
 * org.amdatu.deployment:org.amdatu.deployment.autoconf
 * org.amdatu.eventadmin:org.amdatu.multitenant.org.apache.felix.eventadmin
 * org.amdatu.preferences:org.amdatu.multitenant.org.apache.felix.prefs
 * org.amdatu.useradmin:org.amdatu.multitenant.org.ops4j.pax.useradmin.pax-useradmin-service
 * org.amdatu.useradmin:org.amdatu.multitenant.org.amdatu.useradmin.pax.fsstorage
 * org.amdatu.web:org.amdatu.web.dispatcher
 * org.amdatu.web:org.amdatu.web.httpcontext
 * org.amdatu.httpservice:org.amdatu.multitenant.org.apache.felix.http.jetty
 * org.amdatu.web:org.amdatu.web.jaxrs
 * org.amdatu.web:org.amdatu.web.tenantresolver.hostname
 * org.amdatu.web:org.amdatu.web.tenantresolver.parameter
 * org.amdatu.web:org.amdatu.web.wink
 * org.amdatu.kitchensink:org.amdatu.kitchensink.demo.tenant.global
 * org.amdatu.kitchensink:org.amdatu.kitchensink.demo.tenant.local
 * org.amdatu.kitchensink:org.amdatu.kitchensink.demo.tenant.web
I used the config files in the kitchensink (release-server/src/main/resources/config/demo-multitenant).
The versions of the Amdatu bundles is 1.0.0-SNAPSHOT.

When I randomly add/remove bundles, things break. I haven't been able to construct a step-by-step
'manual' to reproduce it, but there are some things that I found remarkable.
 * The problem seems to be something with the config files (by which I mean the .xml files
and not the .tenant files);
 * if you provision the config files one by one, it usually doesn't break, although it does
happen sometimes;
 * if you provision multiple config files at once, it usually breaks;
 * if you managed to provision several config files, shutdown the agent, clean its cache and
restart it, it always breaks (well, it did for me);
 * after it broke, you won't be able to always fix it, since the target seems to 'freeze'.
You can still add/remove bundles, provision them, etc, but the provisioning state remains
'Failed', whatever you do. However, the available version etc, does change. The only 'fix'
is a restart with clean cache.
 * Even if you manage to provision the config files, they're ignored.
Note: by 'breaking' I mean that the provisioning fails, the state being 'Failed'.

Neither the server, nor the agent seems to log anything useful for this, so unfortunately,
I've got no logs on this bug.
                  
> Target no longer resolves after randomly adding/removing bundles.
> -----------------------------------------------------------------
>
>                 Key: ACE-269
>                 URL: https://issues.apache.org/jira/browse/ACE-269
>             Project: ACE
>          Issue Type: Bug
>          Components: Web UI
>         Environment: Windows 7, With authentication enabled (all config filed adapted,
login d/f)
>            Reporter: Matthijs Hendriks
>            Priority: Critical
>
> If you deploy a clean agent (I used the ace launcher) on a clean server (I used the ace
devserver), the target appears and resolves. However, if I deploy the Amdatu kitchensink on
it, including the local and web demo, it no longer does. Even after I then detach *all* bundles,
distributions and features from the target, the target won't resolve.
> I managed to do this 2 out of 2 times, using the method explained above. The first time
I got no exceptions, but the second time I got a giant list of the same exception over and
over again, being:
> 2012.05.01 10:22:32 WARNING - Bundle: org.apache.felix.http.jetty - /deployment/defaultTargetID/versions/38.0.0
- java.lang.RuntimeException: org.mortbay.jetty.EofException
>         at org.apache.ace.deployment.servlet.DeploymentServlet.tryClose(DeploymentServlet.java:243)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.handlePackageDelivery(DeploymentServlet.java:218)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.doGet(DeploymentServlet.java:100)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.service(DeploymentServlet.java:132)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>         at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
>         at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
>         at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
>         at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
>         at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
>         at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
>         at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
>         at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>         at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>         at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
>         at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>         at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>         at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>         at org.mortbay.jetty.Server.handle(Server.java:326)
>         at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>         at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
>         at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>         at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>         at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>         at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>         at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> Caused by: org.mortbay.jetty.EofException
>         at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:789)
>         at org.mortbay.jetty.HttpConnection.flushResponse(HttpConnection.java:693)
>         at org.mortbay.jetty.HttpConnection$Output.close(HttpConnection.java:997)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.tryClose(DeploymentServlet.java:238)
>         ... 27 more
> Caused by: java.io.IOException: An established connection was aborted by the software
in your host machine
>         at sun.nio.ch.SocketDispatcher.write0(Native Method)
>         at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
>         at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:69)
>         at sun.nio.ch.IOUtil.write(IOUtil.java:26)
>         at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
>         at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:169)
>         at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:221)
>         at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:723)
>         ... 30 more
> 2012.05.01 10:22:32 WARNING - Bundle: org.apache.ace.deployment.servlet - Exception trying
to close stream after request.  - org.mortbay.jetty.EofException
>         at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:789)
>         at org.mortbay.jetty.HttpConnection.flushResponse(HttpConnection.java:693)
>         at org.mortbay.jetty.HttpConnection$Output.close(HttpConnection.java:997)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.tryClose(DeploymentServlet.java:238)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.handlePackageDelivery(DeploymentServlet.java:218)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.doGet(DeploymentServlet.java:100)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>         at org.apache.ace.deployment.servlet.DeploymentServlet.service(DeploymentServlet.java:132)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>         at org.apache.felix.http.base.internal.handler.ServletHandler.doHandle(ServletHandler.java:96)
>         at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:79)
>         at org.apache.felix.http.base.internal.dispatch.ServletPipeline.handle(ServletPipeline.java:42)
>         at org.apache.felix.http.base.internal.dispatch.InvocationFilterChain.doFilter(InvocationFilterChain.java:49)
>         at org.apache.felix.http.base.internal.dispatch.HttpFilterChain.doFilter(HttpFilterChain.java:33)
>         at org.apache.felix.http.base.internal.dispatch.FilterPipeline.dispatch(FilterPipeline.java:48)
>         at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:39)
>         at org.apache.felix.http.base.internal.DispatcherServlet.service(DispatcherServlet.java:67)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>         at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>         at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
>         at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>         at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>         at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>         at org.mortbay.jetty.Server.handle(Server.java:326)
>         at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>         at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
>         at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>         at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>         at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>         at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>         at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> Caused by: java.io.IOException: An established connection was aborted by the software
in your host machine
>         at sun.nio.ch.SocketDispatcher.write0(Native Method)
>         at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
>         at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:69)
>         at sun.nio.ch.IOUtil.write(IOUtil.java:26)
>         at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
>         at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:169)
>         at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:221)
>         at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:723)
>         ... 30 more
> If I stop the agent and restart it with a cleaned cache (that is, I removed the folder
named felix-cache) it works again.
> NOTE: When adding/removing bundles, I did this in a 'bulk-way'. I selected multiple bundles
and provisioned/deprovisioned (I did *not* remove the bundles entirely from the view) them,
instead of one by one.
> I got this exception in the target console. However, I'm not sure if it is related, since
I'm not sure when it was thrown (sorry for that)
> Exception in thread "Apache Felix DeploymentAdmin - ExplodingOutputtingInputStream" java.lang.NullPointerException
>      at org.apache.felix.deploymentadmin.ExplodingOutputtingInputStream.run(ExplodingOutputtingInputStream.java:116)
>      at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message