Mailing-List: contact commits-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ace.apache.org
Date: Tue, 22 May 2012 14:47:42 +0000 (UTC)
From: "Matthijs Hendriks (JIRA)" <jira@apache.org>
To: commits@ace.apache.org
Message-ID: <994084158.8221.1337698062313.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <1980630574.12736.1335861344697.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (ACE-269) Target no longer resolves after
 randomly adding/removing bundles.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Matthijs Hendriks commented on ACE-269:
---------------------------------------

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