Re: [Hypercontent-users] Is this a bug , workflow takes time to load

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Alex,

I sent the only exception I got in the log.

UAT is on Fedora CORE 5, with internal storage.

STAFF access via tomcat 5.5.20 on port 8080 for
content editing and will publish to Apache 2.2 (runs
in the same machine) for serving students.

Production will be same setup with Linux Advanced
server with mod_jk for staff as well.

Thanks

--- Alex Vigdor <al...@bi...> wrote:

> 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:
> 
=== message truncated ===

____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html 