[Building Sakai] Question about Samigo and RemoveAssessmentThread

[Cris J Holdorph]

It depends on how you define performance issue.  If you think about it, 
*IF* (we're guessing here) the reason it has to be in a thread is that 
the action can take a long time, and we want the user to have a good 
user experience....   Well then one has to ask the question what about 
"remove assessment" is taking a long time.  If the reason it takes a 
long time is that it does a lot of database calls, then there could be 
an impact to the Sakai server.  We ran out of memory.  And when we ran 
out of memory and did a thread dump we saw several of these threads 
running.  It could be a coincidence.  However, we ran out of memory 3 
times in about 24 hours.  We tracked down the person who was removing 
assessments and asked them to stop while investigated this problem. 
Since that person has stopped removing assessments, we have not run out 
of memory.

There is a strong correlation that this person removing assessments 
caused our out of memory problems.  Now this is not proof, just a 
correlation.  We're still investigating.  I was merely asking the 
question, because any additional information someone had, might have 
helped in our investigation.

---- Cris J H

On 07/02/2014 11:46 AM, Karen Tsao wrote:
> Hi Cris,
>
> The developer who implemented this doesn't work with us anymore and so
> we cannot get the reason from him. However, after discussing with Lydia,
> we guess the reason he implemented this way might be for improving user
> experience - he didn't want the user to wait on the Remove Assessment
> page until the assessment is removed. By using the thread, the user can
> continue to work on what he wants to do next.
>
> Also, this has been implemented since day 1. If this is causing
> performance issue, I think this should come up earlier?
>
> Thanks,
> Karen
>
>
>
> On Tue, Jul 1, 2014 at 10:53 AM, Cris J Holdorph <holdorph at unicon.net
> <mailto:holdorph at unicon.net>> wrote:
>
>     We have a production system that has run out of memory 3 times in the
>     last two days (just over 24 hours).  The memory dump the system admin
>     took, showed a few instances of the samigo "RemoveAssessmentThread"
>     running.
>
>     I looked into that code, and I'm confused as to why this code has to be
>     a thread at all.  It really only seems to do two things:
>
>     assessmentService.removeAssessment(this.assessmentId);
>     EventTrackingService.post(EventTrackingService.newEvent("sam.assessment.remove",
>     "assessmentId=" + assessmentId, context,
>     true,NotificationService.NOTI_NONE));
>
>     I tried to look through the subversion logs, but it looks like this
>     thread existed right from day one when the code base was imported into
>     subversion from cvs.  So no clues there.
>
>     Does anyone know why this code exists as a separate thread?  Is there
>     any reason why this couldn't/shouldn't be simplified and just done
>     without the use of a Thread?
>
>     ---- Cris J H
>     _______________________________________________
>     sakai-dev mailing list
>     sakai-dev at collab.sakaiproject.org
>     <mailto:sakai-dev at collab.sakaiproject.org>
>     http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
>     TO UNSUBSCRIBE: send email to
>     sakai-dev-unsubscribe at collab.sakaiproject.org
>     <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
>     subject of "unsubscribe"
>
>