ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wilfried Sibla (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-371) DeploymentRepository corrupt after bulk update through REST client
Date Mon, 22 Jul 2013 10:20:49 GMT

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

Wilfried Sibla commented on ACE-371:
------------------------------------

I don't really know your test setup for the bulk changes via REST API, but after thinking
a little bit about this, I think that's understandable.
If during a REST call checkout, change and a commit are performed, the changes are published
asynchronously through the repo and the repo object. This asynchronous processing could take
a while and the next REST call is received before the repo is calculated. But may be that
I'm wrong :-)

Here's a possible explanation:
http://java.dzone.com/articles/osgi-postevent-vs-sendevent
Accordingly to this article, afaik the ACE repos are also registering a lots event listener
etc.
                
> DeploymentRepository corrupt after bulk update through REST client
> ------------------------------------------------------------------
>
>                 Key: ACE-371
>                 URL: https://issues.apache.org/jira/browse/ACE-371
>             Project: ACE
>          Issue Type: Bug
>          Components: Repository
>    Affects Versions: 1.0.0
>            Reporter: Bram de Kruijff
>            Priority: Critical
>
> After doing a bulk update on a REST client workspace. The deployment repository seems
to be corrupted. There are a few strange things;
> 1) The initial run succeeds and my target gets a dp with version 1.0.0
> 2) After a second run, that deletes and recreated the artifacts, I get;
>  -> the target reports remote version "undefined", caused by the deployment api reporting
no versions. The server logs reports the stacks below;  
>  -> the webui does report an available that is very high. In my case it increases
by about 150 per run
> It seems that the underlying cause to getVersions being null is in 
> {code}
> 2013.07.11 21:15:57 WARNING - Bundle: org.apache.ace.deployment.servlet - 500:Error getting
available versions. - org.apache.felix.log.LogException: org.apache.ace.deployment.servlet.AceRestException:
500:Error getting available versions.
> 	at org.apache.ace.deployment.servlet.DeploymentServlet.getVersions(DeploymentServlet.java:234)
> 	at org.apache.ace.deployment.servlet.DeploymentServlet.doGet(DeploymentServlet.java:92)
> 	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)
> 2013.07.11 21:15:57 WARNING - Bundle: org.apache.ace.deployment.servlet - Error getting
available versions. - java.io.EOFException
> 	at java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:264)
> 	at java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:254)
> 	at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:163)
> 	at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:78)
> 	at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:90)
> 	at org.apache.ace.deployment.provider.repositorybased.RepositoryBasedProvider.getRepositoryStream(RepositoryBasedProvider.java:419)
> 	at org.apache.ace.deployment.provider.repositorybased.RepositoryBasedProvider.getVersions(RepositoryBasedProvider.java:211)
> 	at org.apache.ace.deployment.servlet.DeploymentServlet.getVersions(DeploymentServlet.java:227)
> 	at org.apache.ace.deployment.servlet.DeploymentServlet.doGet(DeploymentServlet.java:92)
> 	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)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message