History | Log In     View a printable version of the current page.  
   HOME       BROWSE PROJECT       FIND ISSUES       CREATE NEW ISSUE   
    QUICK SEARCH:  
Issue Details (XML | Word | Printable)

Key: AMATH-863
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Fix
Priority: Blocker Blocker
Assignee: Unassigned
Reporter: Stefan Winterstein
Votes: 0
Watchers: 3
Operations

Link this issue to another issue
If you were logged in you would be able to see more operations.
ActiveMath

XLM can hang for a very long time

Created: 2006-07-20 15:07   Updated: 2006-11-09 16:11
Component/s: XLM: Learner Model
Affects Version/s: None
Fix Version/s: 1.0

Time Tracking:
Not Specified

File Attachments: 1. Text File activemath-AMATH-863.log (341 kb)
2. Java Source File XlmSession.java (16 kb)


 Description  « Hide
Recently, I'm again experiencing deadlocks of the XLM. They might be related to Rafaels changes from July 17th.

Here are 2 stacktraces from a deadlock state:

> Thread [Thread-8] (Suspended)
> Object.wait(long) line: not available [native method]
> XlmSession(Object).wait() line: not available
> XlmSession.open(int) line: 199
> XlmSession.getSession(String, int) line: 183
> XlmModelImpl.getSessionReadOnly(String) line: 557
> XlmModelImpl.getBelief(String, String, String) line: 326
> XlmModelImpl.getBelief(String, String) line: 271
> XlmModelImpl.getSummaryBelief(String, String) line: 288
> XlmManager.getSummaryBelief(String, String) line: 450
> XlmAdapter.getKnowledgeValue(String, String) line: 78
> User.getMastery(String) line: 487
> UserBeanFactory.createUserItem(User, Item, Formatter) line: 87
> UserBeanFactory.createUserItem(User, Item) line: 97
> ExerciseController.action() line: 393
> ExerciseController(ControllerBase).perform() line: 711
> ExerciseController(ThrowawayBean2).go() line: 44
> ExerciseController(Throwaway2).go(ControllerContext) line: 48
> ThrowawayControllerAdapter.go(ControllerContext) line: 58
> CommandMultipleViews(CommandBase).go(MaverickContext) line: 44
> Dispatcher.service(HttpServletRequest, HttpServletResponse) line: 198
> Dispatcher(HttpServlet).service(ServletRequest, ServletResponse) line: 853
> ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 247
> ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 193
> StandardWrapperValve.invoke(Request, Response, ValveContext) line: 256
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> StandardPipeline.invoke(Request, Response) line: 480
> StandardWrapper(ContainerBase).invoke(Request, Response) line: 995
> StandardContextValve.invoke(Request, Response, ValveContext) line: 191
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> StandardPipeline.invoke(Request, Response) line: 480
> StandardContext(ContainerBase).invoke(Request, Response) line: 995
> StandardContext.invoke(Request, Response) line: 2416
> StandardHostValve.invoke(Request, Response, ValveContext) line: 180
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> ErrorDispatcherValve.invoke(Request, Response, ValveContext) line: 171
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
> ErrorReportValve.invoke(Request, Response, ValveContext) line: 172
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
> AccessLogValve.invoke(Request, Response, ValveContext) line: 577
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
> StandardPipeline.invoke(Request, Response) line: 480
> StandardHost(ContainerBase).invoke(Request, Response) line: 995
> StandardEngineValve.invoke(Request, Response, ValveContext) line: 174
> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> StandardPipeline.invoke(Request, Response) line: 480
> StandardEngine(ContainerBase).invoke(Request, Response) line: 995
> CoyoteAdapter.service(Request, Response) line: 223
> Http11Processor.process(InputStream, OutputStream) line: 601
> Http11Protocol$Http11ConnectionHandler.processConnection(TcpConnection, Object[]) line: 392
> TcpWorkerThread.runIt(Object[]) line: 565
> ThreadPool$ControlRunnable.run() line: 619
> ThreadWithAttributes(Thread).run() line: not available

> Thread [AsyncEventPropagator for org.activemath.xlm.model.XlmModelImpl@1f5438] (Suspended)
> FileChannelImpl.force0(FileDescriptor, boolean) line: not available [native method]
> FileChannelImpl.force(boolean) line: not available
> DirRandomAccessFile4.sync(boolean) line: not available
> LogAccessFile.syncLogAccessFile() line: not available
> LogToFile.flush(long, long) line: not available
> LogToFile.flush(LogInstant) line: not available
> FileLogger.flush(LogInstant) line: not available
> Xact.prepareCommit(int) line: not available
> Xact.commit(int) line: not available
> Xact.commit() line: not available
> RAMTransaction.commit() line: not available
> GenericLanguageConnectionContext.doCommit(boolean, boolean, int, boolean) line: not available
> GenericLanguageConnectionContext.userCommit() line: not available
> TransactionResourceImpl.commit() line: not available
> EmbedConnection30(EmbedConnection).commit() line: not available
> JDBCTransaction.commitAndResetAutoCommit() line: 119
> JDBCTransaction.commit() line: 95
> XlmSession.persistBeliefDescriptor(BeliefDescriptor) line: 395
> LMUpdaterImpl.distributeEvidence(Map) line: 127
> LMUpdaterImpl.processEvent(ActivemathEvent) line: 102
> XlmModelImpl.onActivemathEvent(ActivemathEvent) line: 139
> AsyncEventPropagator.deliverEventsAsync() line: 55
> AsyncEventPropagator.run() line: 34



 All   Comments   Work Log   Change History   Version Control   FishEye   Crucible   Related Builds      Sort Order: Ascending order - Click to sort in descending order
[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-20 15:07
I can reproduce this behavior right now:

What happens is that the second exercise is started right after the first one finishes.

Maybe XLM chokes on handling ExericseFinished and ExerciseStarted concurrently?

Will attach the logfile.


[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-20 15:07
Here's the log.

Watch the last few lines: the system begins to crawl at 15:37:05,024 and deadlocks at 15:38:25.


[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-20 15:07
Big news: XLM is not deadlocked, it's just taking it's time!

2006-07-20 15:38:25,789 INFO model.LMUpdaterImpl - Beliefs updated for learner: winter
2006-07-20 15:44:27,696 INFO model.XlmModelImpl - Stopwatch: Recovering of a summary belief: StopWatch: running time (secs)=442.672; [Recovering mathematical competency id] took 0.0=0%; [Creating xLM session] took 441.64=100%; [Recovering topics] took 0.0=0%; [Calculating beliefs] took 0.016=0%; [Releasing xLM session] took 1.016=0%

So it was stuck for 441 seconds in creating the XLM session....

Very weird...


[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-20 15:07
Changed the title to reflect the new situation.

[ Permlink | « Hide ]
Rafael Morales - 2006-07-20 17:07
I will try to provide a summary of the situation so that we can all plan what can be done in this respect. The idea behind the current implementation of xLM is speed up (yes, keep reading) the recovery of beliefs from learner models, so it loads the full learner model when the user logs in and it is unload when the user logs out. The main problem with this situation is that xLM (actually, XlmSession) has to deal with concurrent access to the objects in memory and uses a very simple, non optimised mechanism for it.

Now, after reading again the Hibernate manual I discovered that Hibernate sessions are not thread safe (a dangerous situation for the current implementation) but that, if properly restricted to a single thread, they can deal with concurrent access to objects in the database. Hence the ideas for an optimised implementation of XlmSession are:

  • Every user (of an XlmSession, i.e. every query for XlmSession.getSession(...)) gets an instance of XlmSession which is attached to a single Hibernate session to access the learner model.
  • Information is recovered from the database as needed, inside a Hibernate session (the manual recommends that).
  • We can use the second-level cache to improve on performance.

The changes so far committed are nothing to do with all this. Only cleaning up of useless complicated coding (and xLM does not process ExerciseStarted events so far). On the other hand, I have implemented the first two items above which should have the effect of quicker starting up (confirmed) and better concurrent access to beliefs (to be confirmed). However, despite what the manual says, I have been unable to recover beliefs that way, even slowly. I may be making a mistake, due to some omision or misunderstanding of Hibernate. I have sent my code for feedback to Stefan and Eric...

That is how I see the situation, and I will appreciate your feedback.

Regards,

Rafael


[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-21 09:07
Here's the revised code Rafael mentioned.

I did a brief test: access to the XLM session with this code is very slow/hangs on init. The stacktrace is appended, maybe it gives us a clue.

Sorry, not more time for now.

-Stefan

> > Thread [Thread-8] (Suspended)
> > EntityMetamodel.getTuplizer(EntityMode) line: 90
> > SingleTableEntityPersister(BasicEntityPersister).getTuplizer(EntityMode) line: 2605
> > SingleTableEntityPersister(BasicEntityPersister).setPropertyValues(Object, Object[], EntityMode) line: 2919
> > TwoPhaseLoad.initializeEntity(Object, boolean, SessionImplementor, PreLoadEvent, PostLoadEvent) line: 113
> > OneToManyLoader(Loader).initializeEntitiesAndCollections(List, Object, SessionImplementor, boolean) line: 530
> > OneToManyLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 436
> > OneToManyLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 218
> > OneToManyLoader(Loader).loadCollectionBatch(SessionImplementor, Serializable[], Type) line: 1472
> > BatchingCollectionInitializer.initialize(Serializable, SessionImplementor) line: 47
> > OneToManyPersister(AbstractCollectionPersister).initialize(Serializable, SessionImplementor) line: 488
> > DefaultInitializeCollectionEventListener.onInitializeCollection(InitializeCollectionEvent) line: 60
> > SessionImpl.initializeCollection(PersistentCollection, boolean) line: 1430
> > PersistentList(AbstractPersistentCollection).forceInitialization() line: 280
> > PersistenceContext.initializeNonLazyCollections() line: 796
> > CriteriaLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 223
> > CriteriaLoader(Loader).doList(SessionImplementor, QueryParameters) line: 1593
> > CriteriaLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type[]) line: 1577
> > CriteriaLoader.list(SessionImplementor) line: 111
> > SessionImpl.list(CriteriaImpl) line: 1322
> > CriteriaImpl.list() line: 300
> > CriteriaImpl.uniqueResult() line: 433
> > XlmSession.<init>(String, int) line: 186
> > XlmSession.getSession(String, int) line: 78
> > XlmModelImpl.getSessionReadOnly(String) line: 557
> > XlmModelImpl.getSummaryBeliefs(String, String, List) line: 715
> > XlmModelImpl.getSummaryBeliefs(String, List) line: 764
> > XlmManager.getSummaryBeliefs(String, List) line: 642
> > XlmAdapter.getKnowledgeValues(String, List) line: 93
> > User.getMasteries(List) line: 492
> > UserBeanFactory.getAllKnowledgeValues(TocEntry, User) line: 235
> > UserBeanFactory.createUserToc(User, TocEntry, Formatter) line: 200
> > UserBeanFactory.createUserToc(User, TocEntry) line: 253
> > Toc.action() line: 99
> > Toc(ControllerBase).perform() line: 711
> > Toc(ThrowawayBean2).go() line: 44
> > Toc(Throwaway2).go(ControllerContext) line: 48
> > ThrowawayControllerAdapter.go(ControllerContext) line: 58
> > CommandMultipleViews(CommandBase).go(MaverickContext) line: 44
> > Dispatcher.service(HttpServletRequest, HttpServletResponse) line: 198
> > Dispatcher(HttpServlet).service(ServletRequest, ServletResponse) line: 853
> > ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 247
> > ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 193
> > StandardWrapperValve.invoke(Request, Response, ValveContext) line: 256
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> > StandardPipeline.invoke(Request, Response) line: 480
> > StandardWrapper(ContainerBase).invoke(Request, Response) line: 995
> > StandardContextValve.invoke(Request, Response, ValveContext) line: 191
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> > StandardPipeline.invoke(Request, Response) line: 480
> > StandardContext(ContainerBase).invoke(Request, Response) line: 995
> > StandardContext.invoke(Request, Response) line: 2416
> > StandardHostValve.invoke(Request, Response, ValveContext) line: 180
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> > ErrorDispatcherValve.invoke(Request, Response, ValveContext) line: 171
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
> > ErrorReportValve.invoke(Request, Response, ValveContext) line: 172
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
> > AccessLogValve.invoke(Request, Response, ValveContext) line: 577
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
> > StandardPipeline.invoke(Request, Response) line: 480
> > StandardHost(ContainerBase).invoke(Request, Response) line: 995
> > StandardEngineValve.invoke(Request, Response, ValveContext) line: 174
> > StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
> > StandardPipeline.invoke(Request, Response) line: 480
> > StandardEngine(ContainerBase).invoke(Request, Response) line: 995
> > CoyoteAdapter.service(Request, Response) line: 223
> > Http11Processor.process(InputStream, OutputStream) line: 601
> > Http11Protocol$Http11ConnectionHandler.processConnection(TcpConnection, Object[]) line: 392
> > TcpWorkerThread.runIt(Object[]) line: 565
> > ThreadPool$ControlRunnable.run() line: 619
> > ThreadWithAttributes(Thread).run() line: not available


[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-26 10:07
I did a fresh install and solved a single exercise. There was a hang of about 90 seconds.

Here's an exception stacktrace:

org.activemath.xlm.model.XlmException: could not initialize a collection batch: [org.activemath.xlm.m
odel.Belief.evidence#<65789, 65787, 65781, 65783, 65784, 65785, 65786, 65788>]
at org.activemath.xlm.model.XlmSession.<init>(XlmSession.java:201)
at org.activemath.xlm.model.XlmSession.getSession(XlmSession.java:77)
at org.activemath.xlm.model.XlmModelImpl.getSessionReadOnly(XlmModelImpl.java:557)
at org.activemath.xlm.model.XlmModelImpl.getBelief(XlmModelImpl.java:326)
at org.activemath.xlm.model.XlmModelImpl.getBelief(XlmModelImpl.java:271)
at org.activemath.xlm.model.XlmModelImpl.getSummaryBelief(XlmModelImpl.java:288)
at org.activemath.xlm.XlmManager.getSummaryBelief(XlmManager.java:450)
at org.activemath.webapp.user.learner.XlmAdapter.getKnowledgeValue(XlmAdapter.java:78)
at org.activemath.webapp.user.User.getMastery(User.java:487)
at org.activemath.webapp.user.UserBeanFactory.createUserItem(UserBeanFactory.java:87)
at org.activemath.webapp.user.UserBeanFactory.createUserItem(UserBeanFactory.java:123)
at org.activemath.webapp.user.UserBeanFactory.createUserItem(UserBeanFactory.java:116)
at org.activemath.webapp.user.UserBeanFactory.calcMastery(UserBeanFactory.java:334)
at org.activemath.webapp.user.UserBeanFactory.adaptTocRecursivly(UserBeanFactory.java:276)
at org.activemath.webapp.user.UserBeanFactory.adaptTocRecursivly(UserBeanFactory.java:283)
at org.activemath.webapp.user.UserBeanFactory.createUserToc(UserBeanFactory.java:201)
at org.activemath.webapp.user.UserBeanFactory.createUserToc(UserBeanFactory.java:251)
at org.activemath.webapp.controller.ViewBook.action(ViewBook.java:189)
at org.activemath.webapp.base.ControllerBase.perform(ControllerBase.java:711)
at org.infohazard.maverick.ctl.ThrowawayBean2.go(ThrowawayBean2.java:44)
at org.infohazard.maverick.ctl.Throwaway2.go(Throwaway2.java:48)
at org.infohazard.maverick.flow.ThrowawayControllerAdapter.go(ThrowawayControllerAdapter.java
:58)
at org.infohazard.maverick.flow.CommandBase.go(CommandBase.java:44)
at org.infohazard.maverick.Dispatcher.service(Dispatcher.java:198)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja
va:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
Pipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:601)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Pr
otocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:534)
2006-07-26 10:59:16,282 INFO model.XlmModelImpl - Stopwatch: Recovering of a summary belief: StopWa
tch: running time (secs)=60.755; [Recovering mathematical competency id] took 0.0=0%; [Creating xLM s
ession] took 60.755=100%


[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-26 11:07
FYI, the last comment was with the full automatic DomainMap enabled.

[ Permlink | « Hide ]
Stefan Winterstein - 2006-07-26 11:07
The long delays from my last comment went away when I changed the config back to the internal domain map of XLM, at least for now.

So when investigation this, we should keep in mind that the automatic domain map is an important factor.

OTOH, when doing a server setup for Carsten last week, the XLM had hangs even running with the internal domain map, so I would point to it as the single cause.


[ Permlink | « Hide ]
Rafael Morales - 2006-07-26 19:07
Hello Stefan,

Thank you for the information. By now you should have received a copy of
the email sent to Erica. As I said there, an important problem is that
XlmSession cannot make use of the lazy fetching characteristics of
Hibernate. I do not know why. I have revised the manual and have not
idea. I will send a request to the Hibernate forum, hoping someone
answers back.

Rafael

Stefan Winterstein (JIRA) escribió:
> [ http://jira.activemath.org//browse/AMATH-863?page=comments#action_12723 ]
>
> Stefan Winterstein commented on AMATH-863:
> ------------------------------------------
>
> I did a fresh install and solved a single exercise. There was a hang of about 90 seconds.
>
> Here's an exception stacktrace:
>
> org.activemath.xlm.model.XlmException: could not initialize a collection batch: [org.activemath.xlm.m
> odel.Belief.evidence#<65789, 65787, 65781, 65783, 65784, 65785, 65786, 65788>]
> at org.activemath.xlm.model.XlmSession.<init>(XlmSession.java:201)
> at org.activemath.xlm.model.XlmSession.getSession(XlmSession.java:77)
> at org.activemath.xlm.model.XlmModelImpl.getSessionReadOnly(XlmModelImpl.java:557)
> at org.activemath.xlm.model.XlmModelImpl.getBelief(XlmModelImpl.java:326)
> at org.activemath.xlm.model.XlmModelImpl.getBelief(XlmModelImpl.java:271)
> at org.activemath.xlm.model.XlmModelImpl.getSummaryBelief(XlmModelImpl.java:288)
> at org.activemath.xlm.XlmManager.getSummaryBelief(XlmManager.java:450)
> at org.activemath.webapp.user.learner.XlmAdapter.getKnowledgeValue(XlmAdapter.java:78)
> at org.activemath.webapp.user.User.getMastery(User.java:487)
> at org.activemath.webapp.user.UserBeanFactory.createUserItem(UserBeanFactory.java:87)
> at org.activemath.webapp.user.UserBeanFactory.createUserItem(UserBeanFactory.java:123)
> at org.activemath.webapp.user.UserBeanFactory.createUserItem(UserBeanFactory.java:116)
> at org.activemath.webapp.user.UserBeanFactory.calcMastery(UserBeanFactory.java:334)
> at org.activemath.webapp.user.UserBeanFactory.adaptTocRecursivly(UserBeanFactory.java:276)
> at org.activemath.webapp.user.UserBeanFactory.adaptTocRecursivly(UserBeanFactory.java:283)
> at org.activemath.webapp.user.UserBeanFactory.createUserToc(UserBeanFactory.java:201)
> at org.activemath.webapp.user.UserBeanFactory.createUserToc(UserBeanFactory.java:251)
> at org.activemath.webapp.controller.ViewBook.action(ViewBook.java:189)
> at org.activemath.webapp.base.ControllerBase.perform(ControllerBase.java:711)
> at org.infohazard.maverick.ctl.ThrowawayBean2.go(ThrowawayBean2.java:44)
> at org.infohazard.maverick.ctl.Throwaway2.go(Throwaway2.java:48)
> at org.infohazard.maverick.flow.ThrowawayControllerAdapter.go(ThrowawayControllerAdapter.java
> :58)
> at org.infohazard.maverick.flow.CommandBase.go(CommandBase.java:44)
> at org.infohazard.maverick.Dispatcher.service(Dispatcher.java:198)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.ja
> va:247)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:643)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:643)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2416)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:643)
> at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:641)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:641)
> at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:641)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
> at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(Standard
> Pipeline.java:643)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:601)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Pr
> otocol.java:392)
> at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
> at java.lang.Thread.run(Thread.java:534)
> 2006-07-26 10:59:16,282 INFO model.XlmModelImpl - Stopwatch: Recovering of a summary belief: StopWa
> tch: running time (secs)=60.755; [Recovering mathematical competency id] took 0.0=0%; [Creating xLM s
> ession] took 60.755=100%
>
>
>
>> XLM can hang for a very long time
>> ---------------------------------
>>
>> Key: AMATH-863
>> URL: http://jira.activemath.org//browse/AMATH-863
>> Project: ActiveMath
>> Type: Bug
>> Components: XLM: Learner Model
>> Reporter: Stefan Winterstein
>> Priority: Blocker
>> Fix For: 1.0
>> Attachments: XlmSession.java, activemath-AMATH-863.log
>>
>> Recently, I'm again experiencing deadlocks of the XLM. They might be related to Rafaels changes from July 17th.
>> Here are 2 stacktraces from a deadlock state:
>>
>>> Thread [Thread-8] (Suspended)
>>> Object.wait(long) line: not available [native method]
>>> XlmSession(Object).wait() line: not available
>>> XlmSession.open(int) line: 199
>>> XlmSession.getSession(String, int) line: 183
>>> XlmModelImpl.getSessionReadOnly(String) line: 557
>>> XlmModelImpl.getBelief(String, String, String) line: 326
>>> XlmModelImpl.getBelief(String, String) line: 271
>>> XlmModelImpl.getSummaryBelief(String, String) line: 288
>>> XlmManager.getSummaryBelief(String, String) line: 450
>>> XlmAdapter.getKnowledgeValue(String, String) line: 78
>>> User.getMastery(String) line: 487
>>> UserBeanFactory.createUserItem(User, Item, Formatter) line: 87
>>> UserBeanFactory.createUserItem(User, Item) line: 97
>>> ExerciseController.action() line: 393
>>> ExerciseController(ControllerBase).perform() line: 711
>>> ExerciseController(ThrowawayBean2).go() line: 44
>>> ExerciseController(Throwaway2).go(ControllerContext) line: 48
>>> ThrowawayControllerAdapter.go(ControllerContext) line: 58
>>> CommandMultipleViews(CommandBase).go(MaverickContext) line: 44
>>> Dispatcher.service(HttpServletRequest, HttpServletResponse) line: 198
>>> Dispatcher(HttpServlet).service(ServletRequest, ServletResponse) line: 853
>>> ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 247
>>> ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 193
>>> StandardWrapperValve.invoke(Request, Response, ValveContext) line: 256
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
>>> StandardPipeline.invoke(Request, Response) line: 480
>>> StandardWrapper(ContainerBase).invoke(Request, Response) line: 995
>>> StandardContextValve.invoke(Request, Response, ValveContext) line: 191
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
>>> StandardPipeline.invoke(Request, Response) line: 480
>>> StandardContext(ContainerBase).invoke(Request, Response) line: 995
>>> StandardContext.invoke(Request, Response) line: 2416
>>> StandardHostValve.invoke(Request, Response, ValveContext) line: 180
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
>>> ErrorDispatcherValve.invoke(Request, Response, ValveContext) line: 171
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
>>> ErrorReportValve.invoke(Request, Response, ValveContext) line: 172
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
>>> AccessLogValve.invoke(Request, Response, ValveContext) line: 577
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 641
>>> StandardPipeline.invoke(Request, Response) line: 480
>>> StandardHost(ContainerBase).invoke(Request, Response) line: 995
>>> StandardEngineValve.invoke(Request, Response, ValveContext) line: 174
>>> StandardPipeline$StandardPipelineValveContext.invokeNext(Request, Response) line: 643
>>> StandardPipeline.invoke(Request, Response) line: 480
>>> StandardEngine(ContainerBase).invoke(Request, Response) line: 995
>>> CoyoteAdapter.service(Request, Response) line: 223
>>> Http11Processor.process(InputStream, OutputStream) line: 601
>>> Http11Protocol$Http11ConnectionHandler.processConnection(TcpConnection, Object[]) line: 392
>>> TcpWorkerThread.runIt(Object[]) line: 565
>>> ThreadPool$ControlRunnable.run() line: 619
>>> ThreadWithAttributes(Thread).run() line: not available
>>> Thread [AsyncEventPropagator for org.activemath.xlm.model.XlmModelImpl@1f5438] (Suspended)
>>> FileChannelImpl.force0(FileDescriptor, boolean) line: not available [native method]
>>> FileChannelImpl.force(boolean) line: not available
>>> DirRandomAccessFile4.sync(boolean) line: not available
>>> LogAccessFile.syncLogAccessFile() line: not available
>>> LogToFile.flush(long, long) line: not available
>>> LogToFile.flush(LogInstant) line: not available
>>> FileLogger.flush(LogInstant) line: not available
>>> Xact.prepareCommit(int) line: not available
>>> Xact.commit(int) line: not available
>>> Xact.commit() line: not available
>>> RAMTransaction.commit() line: not available
>>> GenericLanguageConnectionContext.doCommit(boolean, boolean, int, boolean) line: not available
>>> GenericLanguageConnectionContext.userCommit() line: not available
>>> TransactionResourceImpl.commit() line: not available
>>> EmbedConnection30(EmbedConnection).commit() line: not available
>>> JDBCTransaction.commitAndResetAutoCommit() line: 119
>>> JDBCTransaction.commit() line: 95
>>> XlmSession.persistBeliefDescriptor(BeliefDescriptor) line: 395
>>> LMUpdaterImpl.distributeEvidence(Map) line: 127
>>> LMUpdaterImpl.processEvent(ActivemathEvent) line: 102
>>> XlmModelImpl.onActivemathEvent(ActivemathEvent) line: 139
>>> AsyncEventPropagator.deliverEventsAsync() line: 55
>>> AsyncEventPropagator.run() line: 34
>>>
>
>


[ Permlink | « Hide ]
Stefan Winterstein - 2006-11-09 16:11
Seems like we have to live with it.


Powered by a free Atlassian JIRA open source license for ActiveMath . Try JIRA - bug tracking software for your team.
Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.12.2-#300) - Bug/feature request - Atlassian news - Contact Administrators