I have been trying to validate the overlays for the latest service package 6.5.15.0 , but I get a timeout error message almost instantly despite setting the config to a longer time (I tried both 600 seconds and 3600). Any idea why this might happen? Possible fixes? Error message in crx/de is below.
java.io.IOException: Time limit for validation has exceeded default limit and hence not able to validate. Please modify Package Manager Validation Configuration. at com.day.crx.packaging.impl.J2EEPackageManager.consoleValidate(J2EEPackageManager.java:487) at com.day.crx.packaging.impl.J2EEPackageManager.doPost(J2EEPackageManager.java:201) at com.day.crx.packaging.impl.PackageManagerServlet.doPost(PackageManagerServlet.java:172) at javax.servlet.http.HttpServlet.service(HttpServlet.java:644) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:123) at org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:86) at com.adobe.granite.license.impl.LicenseCheckFilter.doFilter(LicenseCheckFilter.java:308) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:142) at org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81) at org.apache.sling.i18n.impl.I18NFilter.doFilter(I18NFilter.java:131) at org.apache.felix.http.base.internal.handler.FilterHandler.handle(FilterHandler.java:142) at org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.java:81) at org.apache.felix.http.base.internal.dispatch.Dispatcher$1.doFilter(Dispatcher.java:146) at org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1002) at com.adobe.granite.auth.oauth.impl.OAuthCallbackFilter.doFilter(OAuthCallbackFilter.java:69) at org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:137) at org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1008) at org.apache.sling.security.impl.ReferrerFilter.doFilter(ReferrerFilter.java:326) at org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:137) at org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1008) at org.apache.felix.http.sslfilter.internal.SslFilter.doFilter(SslFilter.java:97) at org.apache.felix.http.base.internal.handler.PreprocessorHandler.handle(PreprocessorHandler.java:137) at org.apache.felix.http.base.internal.whiteboard.WhiteboardManager$2.doFilter(WhiteboardManager.java:1008) at org.apache.felix.http.base.internal.whiteboard.WhiteboardManager.invokePreprocessors(WhiteboardManager.java:1012) at org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:91) at org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.java:49) at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:799) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) at org.eclipse.jetty.server.Server.handle(Server.java:516) at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388) at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:277) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105) at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:338) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:315) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:173) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:383) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:882) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1036) at java.lang.Thread.run(Unknown Source)
Solved! Go to Solution.
Views
Replies
Total Likes
Hi @DNest19,
In general the only way to handle with this issue is to manipulate Time Limit for Package Validation value from Package Manger Validation Configuration in OSGi.
However there is no any magic value you can set that will guarantee timeout exception will not occur.
The reason for that is there could be different hardware setup you are running your AEM, different content and/or app customization you have on particular AEM. Those factors can have impact on time needed to run specific package validator.
This would not be the case in terms of package size - because if validation will fail due too large size of package, then increasing Package Size Limit for Validation value above the package size will do the job - so this is much simpler and more deterministic.
Anyway, going back to the main issue you have described. The solution will be to experiment with different time limit values if extending values to 3600 did not work try with higher number.
Hi @DNest19,
In general the only way to handle with this issue is to manipulate Time Limit for Package Validation value from Package Manger Validation Configuration in OSGi.
However there is no any magic value you can set that will guarantee timeout exception will not occur.
The reason for that is there could be different hardware setup you are running your AEM, different content and/or app customization you have on particular AEM. Those factors can have impact on time needed to run specific package validator.
This would not be the case in terms of package size - because if validation will fail due too large size of package, then increasing Package Size Limit for Validation value above the package size will do the job - so this is much simpler and more deterministic.
Anyway, going back to the main issue you have described. The solution will be to experiment with different time limit values if extending values to 3600 did not work try with higher number.
Views
Likes
Replies