Attach deployment target failure (PLC)

Got a frantic call last night from an old customer. They use a slightly modified PLC over mulitple branches. TS 731 on Linux.

The same workflow/deployment targets work for other branches. Only 1 file is in the task, so it does not look like a permissions issue. I have reverted to the OOTB PLC. Same issue. The target we use is production, and that is the same in the workflow.

The WF is failing in the Attach Deployment Target step. I am at a loss as to how to debug. I put full debug on and nothing shows from that step with the exception of the Java dump:

2012-12-05 19:41:09,334 [http-0.0.0.0-8080-23] ERROR com.interwoven.livesite.workflow.web.task.AttachDeploymentTargetWebTask () - Error during task execution: Error while communicating with TeamSite: Invalid argument
java.lang.RuntimeException: Error while communicating with TeamSite: Invalid argument
at com.interwoven.livesite.workflow.web.task.AbstractWebTask.handlePostExecution(AbstractWebTask.java:168)
at com.interwoven.livesite.workflow.web.task.AbstractAjaxWebTask.handlePostExecution(AbstractAjaxWebTask.java:137)
at com.interwoven.livesite.workflow.web.task.AbstractAjaxWebTask.execute(AbstractAjaxWebTask.java:73)
at com.interwoven.livesite.workflow.web.action.CSWebTaskAction.execute(CSWebTaskAction.java:110)
at org.springframework.web.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:110)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.interwoven.livesite.spring.hibernate.web.filter.OpenSessionsInViewFilter.doFilterInternal(OpenSessionsInViewFilter.java:108)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:236)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.interwoven.ui.base.impl.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:203)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.interwoven.ui.base.util.SetRequestEncodingFilter.doFilter(SetRequestEncodingFilter.java:106)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.interwoven.cssdk.common.CSException: Attach Deployment Target Success:1793144(Invalid argument)
at com.interwoven.cssdk.sci.exception.ExceptionHandler.handleExceptionSci(ExceptionHandler.java:264)
at com.interwoven.cssdk.sci.workflow.WorkflowServiceSciImpl.chooseTransition(WorkflowServiceSciImpl.java:697)
at com.interwoven.cssdk.workflow.java.WorkflowServiceAdapterImpl.chooseTransition(WorkflowServiceAdapterImpl.java:68)
at com.interwoven.cssdk.workflow.impl.CSTransitionableTaskImpl.chooseTransition(CSTransitionableTaskImpl.java:34)
at com.interwoven.livesite.workflow.WorkflowUtils.handleCallback(WorkflowUtils.java:329)
at com.interwoven.livesite.workflow.web.task.AbstractWebTask.handlePostExecution(AbstractWebTask.java:142)
... 40 more

Any tips/pointers/RTFMs appreciated

Find more posts tagged with

Comments

sheikh1

If it is completely OOTB workflow then I'm guessing something related to target config might be incorrect, I usually rule out if it is a target related issue by creating a new target node and adding that node to copy of PLC workflow.

nipper

If it is completely OOTB workflow then I'm guessing something related to target config might be incorrect, I usually rule out if it is a target related issue by creating a new target node and adding that node to copy of PLC workflow.

No this is before the actual deployment step, just when it is reading the Java Bean about where to deploy content. It is quite strange that it was working earlier in the day and according to the customer, no changes. The GUI was not rebuilt, and there have been no changes to the WF since May.

I did try reseting everything and rebuilding the UI. No help

Rick Poulin

There's a bug deep inside the piece of iwov's code that converts models to jobspec instances. It has to do with their XML parsing putting everything on one line, which overflows the line buffer, and their line wrapping removes what it thinks are extra spaces. Long story short, if the space in your transition name happens to occur in the computed model at a character position that is a multiple of 16384, then it gets lost. The PLC *needs* these spaces because it always looks for transitions of name $task + " " + ("Success"|"Failure"). Run your instance in debug mode as the exact same user and the exact same file attachments, and you'll find that that space is missing in the jobspec (or run iwgetwfobj on your broken task).

TL;DR: it's super specific, super rare, and there's nothing you can do about it other than suggest the client submit a different set of files, which changes the character length of the computed model.

BTW, I've reported this to support through a number of clients who've experienced this and they've still refused to fix it. Last I heard they said "maybe we'll fix this in 7.4".

nipper

Will try that Rick, thanks.

nipper

OK, final issue. There was a copy-to done from the component branch .page, since there was a site without a default.site the Java step croaked.