Re: [Hypercontent-users] Is this a bug , workflow takes time to load
Brought to you by:
alexvigdor
Menu
▾
▴
Re: [Hypercontent-users] Is this a bug , workflow takes time to load
|
From: Alex V. <al...@bi...> - 2007-03-20 12:20:28
|
Hi Tom, You should look for errors earlier in the log that might give a clue as to the root cause. Also, can you describe your server platform? I.e. unix or windows, internal or network storage, NFS or SMB, processor, etc. Alex On Mar 19, 2007, at 9:24 PM, tom tom wrote: > I did all the fixes as suggested by you, but at UAT > following happened > > UAT Content Author (doesnt have approval rights) > started creating all the contents (lot of content). > > Towards the end Author experienced the system is very > slow and complained about that then I asked to send > the log. I have attached the exception, > > I asked the user to delete the file.lock in side > /workflow-data/pending-executables.db. Then everything > is ok > > > I came across similar thing sometime back for > build.xml > and you gave some suggestions to put it as schedulars. > > Can you let me know any recommendation for the above > issue > > > > org.hypercontent.HyperException: Store already engaged > in transaction @ > /workflow-data/pending-executables.db(exists? true) > > at > org.hypercontent.data.impl.AbstractDataStore.beginTransaction > (AbstractDataStore.java:141) > at > org.hypercontent.data.impl.AbstractDataStore.beginTransaction > (AbstractDataStore.java:84) > at > org.hypercontent.data.impl.AbstractDataStore.beginTransaction > (AbstractDataStore.java:80) > at > org.hypercontent.workflow.queue.impl.ExecutableQueue.enqueue > (ExecutableQueue.java:205) > at > org.hypercontent.workflow.queue.impl.ExecutableQueue.enqueue > (ExecutableQueue.java:139) > at > org.hypercontent.workflow.event.EventDispatcher.dispatch > (EventDispatcher.java:64) > at > org.hypercontent.server.commands.NewFile.execute(NewFile.java:286) > at > org.hypercontent.server.ContentServer.service(ContentServer.java:439) > at > org.hypercontent.servlet.CompositionServlet.doGet > (CompositionServlet.java:104) > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:689) > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter > (ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter > (ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke > (StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke > (StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke > (StandardHostValve.java:126) > --- Alex Vigdor <al...@bi...> wrote: > >> >> On Feb 27, 2007, at 5:33 PM, tom tom wrote: >> >>> Alex, >>> I will try it out and let you know, >>> >>> Well...Eventually when this (HC) goes to >> production >>> this will be used by the Authors, Hence there is >>> always a possibility this can happen, >> >> I suggest you deny your authors permission to read >> or write any files >> under /config, e.g. >> >> <permission activity="read" denied="true" >> principal="group:authors" >> target="/config/**/*.*"/> >> <permission activity="read" denied="true" >> principal="group:authors" >> target="/config/**/"/> >> >>> >>> Due to these reasons cant we do the following >>> >>> 1) Have a timeout and release the resources so >> that >>> users will not get this error all the time. Or as >> part >>> of the restart clear the locks. >> >> There is currently a 4 hour lock timeout and a 15 >> second lock wait >> time hard coded. If you'd like to see those moved >> to a properties >> file, or a facility for scheduling workflow tasks >> for startup, please >> submit jira issues. >> >> https://clearinghouse.ja-sig.org/issues/browse/HYP >> >>> >>> >>> 2) Delete unnecessary workflow data triggered by a >>> schedular >>> >>> 3) Mechanism to delete the history data which we >> can >>> see in the workflow screen >> >> In order to delete work data from the repository >> (and therefore on >> screen), you must remove it from any queues it is >> in. You can do this >> on a schedule. For example, in approvals.xml >> >> <q id="archived"> >> <event name="scheduled-discard" when="in 2 hours"> >> <dq where="${path}"/> >> <dq who="${editor}"/> >> <dq/> >> </event> >> ... >> >> or in publish.xml >> >> <q id="published"> >> <event name="scheduled-discard" when="in 2 days"> >> <dq who="${publisher}"/> >> <dq/> >> </event> >> ... >> >> See this page for more scheduling info: >> >> > http://hypercontent.sourceforge.net/help/project/workflow/ >> >> scheduling.html >> >>> >>> Question >>> >>> 1) When the system goes through many >>> Author->Preview->Approve/Reject ->Build>publish >>> >>> Cycles there may be many data collected as part of >>> each workflow, >>> >>> Will this data cause some performance issue >> specially >>> when loading the Workflow Screen,? If so what is >> the >>> mechanism to get rid of that. >> >> Yes, this can cause performance issues loading the >> workflow screen. >> The scheduled events above will address this. >> >>> >>> Basically I want to be prepared if such a thing >>> happens when this goes to production >>> >>> >>> Thanks >>> >>> >>> >>> >>> >>> >>> Let me know your thoughts on this. >>> >>> Thanks >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> --- Alex Vigdor <al...@bi...> wrote: >>> >>>> This is likely the cause of the delays you are >>>> seeing; the system >>>> must be able to acquire a lock on workflow >> scripts >>>> in order to >>>> initialize them, so you have to make sure that >> once >>>> you open a >>>> workflow script for edit, you save or discard >> your >>>> changes. If you >>>> leave the file open the system will time out >> trying >>>> to acquire the lock. >>>> >>>> After things have gotten weird with the workflow >>>> components, its also >>>> a good idea to restart the server. This won't >> clear >>>> the lock, >>>> however - you can manually remove that from the >>>> filesystem by looking >>>> for "/config/workflow/build.xml/file.lock". >>>> >>>> Cheers, >>>> Alex >>>> >>>> On Feb 27, 2007, at 12:33 AM, tom tom wrote: >>>> >>>>> I looked at the catalina.out and it gives an >> Error >>>> as >>>>> follows. >>>>> >>>>> What is the cause for this error. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> <Unable to load workflow build> >>>>> 2007-02-27 16:29:14,781 ERROR >>>>> [org.hypercontent.util.Logger] - <> >>>>> org.hypercontent.HyperException: Store already >>>> engaged >>>>> in transaction @ >>>> /config/workflow/build.xml(exists? >>>>> true) >>>>> at >>>>> >>>> >>> >> > org.hypercontent.data.impl.AbstractDataStore.beginTransaction >>>> >>>>> (AbstractDataStore.java:141) >>>>> at >>>>> >>>> >>> >> > org.hypercontent.data.impl.AbstractDataStore.beginTransaction >>>> >>>>> (AbstractDataStore.java:84) >>>>> at >>>>> >>>> >>> >> > org.hypercontent.data.impl.AbstractDataStore.beginTransaction >>>> >>>>> (AbstractDataStore.java:80) >>>>> at >>>>> >>>> >>> >> > org.hypercontent.workflow.impl.WorkflowFactoryImpl.getWorkflow >>>> >>>>> (WorkflowFactoryImpl.java:137) >>>>> at >> > === message truncated === > > > > > ______________________________________________________________________ > ______________ > Sucker-punch spam with award-winning protection. > Try the free Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/features_spam.html > |
