Return-Path: X-Original-To: apmail-ace-commits-archive@www.apache.org Delivered-To: apmail-ace-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CEA12109A0 for ; Fri, 12 Jul 2013 10:31:55 +0000 (UTC) Received: (qmail 28818 invoked by uid 500); 12 Jul 2013 10:31:55 -0000 Delivered-To: apmail-ace-commits-archive@ace.apache.org Received: (qmail 28793 invoked by uid 500); 12 Jul 2013 10:31:52 -0000 Mailing-List: contact commits-help@ace.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ace.apache.org Delivered-To: mailing list commits@ace.apache.org Received: (qmail 28740 invoked by uid 99); 12 Jul 2013 10:31:48 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2013 10:31:48 +0000 Date: Fri, 12 Jul 2013 10:31:48 +0000 (UTC) From: "Bram de Kruijff (JIRA)" To: commits@ace.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ACE-371) DeploymentRepository corrupt after bulk update through REST client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACE-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13706840#comment-13706840 ] Bram de Kruijff commented on ACE-371: ------------------------------------- Seems to be a race condition. It does not happen every time, but when it happens there is an exception throws while parsing the repository in RepositoryBasedProvider#getVersions() {code} java.net.MalformedURLException: no protocol: itembank.urlhandler.rest-0.0.0.CDS000.jar {code} Wrt to the "high" dp version; It seems a new deployment version is create for every change. It is easy to replay this in the webui. Remove an a2f association, recreate it and store. The version will have been incremented by 2 while, effectively there is no change. In the context of bulk operations this leads to very large increments and big repositories. {code} DeploymentVersionRepositoryImpl.createDeploymentArtifact(String, Map) line: 117 StatefulTargetRepositoryImpl.getNecessaryDeploymentArtifacts(String, String) line: 558 StatefulTargetRepositoryImpl.generateDeploymentVersion(String) line: 662 StatefulTargetRepositoryImpl.approve(String) line: 469 StatefulTargetObjectImpl.approve() line: 79 StatefulTargetObjectImpl.handleStatechangeAutomation() line: 386 StatefulTargetObjectImpl.setStatus(String, String) line: 377 StatefulTargetObjectImpl.setStoreState(StatefulTargetObject$StoreState) line: 367 StatefulTargetObjectImpl.determineStoreState(DeploymentVersionObject) line: 282 StatefulTargetObjectImpl.determineStatus() line: 223 StatefulTargetRepositoryImpl.handleEvent(Event) line: 745 {code} Wrt to changed events in general I am unclear on how these are synchronized with a commit, or if they are at all? It seems all changed events are delivered asynchronous and a commit can happen at any minute. Again, in the context of bulk changes, I think this may be an issue. > 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.(GZIPInputStream.java:78) > at java.util.zip.GZIPInputStream.(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