[SAK-36136] Missing tmp folder leads to Failed import Created: 04-Jan-2012  Updated: 17-Apr-2018  Resolved: 04-Sep-2012

Status: CLOSED
Project: Sakai
Component/s: Tests & Quizzes (Samigo)
Affects Version/s: 2.8.3
Fix Version/s: 2.9.0

Type: Bug Priority: Blocker
Reporter: David Horwitz Assignee: Karen Tsao
Resolution: Fixed Votes: 0
Labels: qatechreview
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File SAM-1537.patch    
2.9 Status: Resolved
Previous Issue Keys: SAM-1537

 Description   

1) In a clean install try import an xml file
2) Upload fails with the following error:

caused by: java.io.FileNotFoundException: /usr/local/sakai/sakai/samigo/answerUploadRepositoryPath/upload_34c5bf50_13460500502_7fd3_00005136.tmp (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:103)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:310)
at com.corejsf.UploadFilter.doFilter(UploadFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:598)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:659)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:457)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:395)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:311)
at org.sakaiproject.jsf.util.SamigoJsfTool.dispatch(SamigoJsfTool.java:301)
at org.sakaiproject.jsf.util.JsfTool.doPost(JsfTool.java:256)

Looking at the instalation [tomcat]/sakai/samigo doesn't exist. Samigo should check it exists first



 Comments   
Comment by Karen Tsao [ 04-Jan-2012 ]

Hi David,

Do you have "samigo.answerUploadRepositoryPath=${sakai.home}/samigo/answerUploadRepositoryPath/" in your sakai.properties? From the error message, your ${sakai.home} is set to "/usr/local/sakai/"?

We follow Sakai's guideline to set this path (https://jira.sakaiproject.org/browse/SAM-662). If your ${sakai.home} doesn't exist, you might have issue with other tools too. So we think this is a setup/configuration issue. What do you think?

Thanks,
Karen

Comment by David Horwitz [ 10-Jan-2012 ]

This can be reporduced on the nightly 2.8 instance: with the following stack:

org.sakaiproject.portal.api.PortalHandlerException: org.sakaiproject.tool.api.ToolException
at org.sakaiproject.portal.charon.handlers.ToolHandler.doPost(ToolHandler.java:73)
caused by: org.sakaiproject.tool.api.ToolException
at org.sakaiproject.portal.charon.SkinnableCharonPortal.forwardTool(SkinnableCharonPortal.java:1429)
caused by: javax.servlet.ServletException
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
caused by: org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/tomcat3/upload_74c7b071_134c63dedde__7fdc_00000000.tmp (No such file or directory)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:310)
caused by: java.io.FileNotFoundException: /tmp/tomcat3/upload_74c7b071_134c63dedde__7fdc_00000000.tmp (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:103)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:310)
at com.corejsf.UploadFilter.doFilter(UploadFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:598)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)

Comment by David Horwitz [ 10-Jan-2012 ]

This is a side isseu from SAM-662 - basicaly on start up Samigo should check the existence of samigo.answerUploadRepositoryPath and if it doesn't exist create it.

Comment by David Horwitz [ 10-Jan-2012 ]

2 further points

  • this property needs better documentation - should this be in a share on a multi node installation? in which case a path based on shared resources (like samigo.answerUploadRepositoryPath) would be better
  • it seems this is being used for tmp upload files (the example here) as well as stored files (the SAM-622 case)
Comment by Lydia Li [ 11-Jan-2012 ]

Yes, this path is used for both temp. upload files, as well as stored files.
In production with multiple node installation, this path should be in a shared file system.

The fix to SAM-662 was mainly to rename the '/tmp' to something else, so it doesn't imply that the folder could be deleted.

Do you think this is still a blocker? Can we lower its priority?

Comment by David Horwitz [ 13-Mar-2012 ]

I still think this is blocker as an OOTB installation is broken. I think the init method of one of the services should check if the folder exists and if not try create it. Failure should be logged as an error.

Comment by Sam Ottenhoff [ 30-Aug-2012 ]

We discussed this on CLE Team call. This is a release blocker for 2.9.x... Can someone add a folder check and create in an init method?

If not, please ask for some help on the list, and we will get someone from CLE Team to do it.

Comment by Adrian Fish [ 03-Sep-2012 ]

I've just reproduced this on my trunk build. I'll submit a patch.

Comment by Adrian Fish [ 03-Sep-2012 ]

Patch attached. I did the test in the bootstrap bean. It seemed to make sense there.

Comment by Matthew Jones [ 04-Sep-2012 ]

I'd probably put
samigoDir.mkdirs();

into an if statement?

if (samigoDir.mkdirs())
LOG.info(samigoDir + " created.");
else
LOG.warn(samigoDir + " unable to be created.");

Comment by Adrian Fish [ 04-Sep-2012 ]

New patch attached. Now extra robust! Thanks Matthew.

Comment by Sam Ottenhoff [ 04-Sep-2012 ]

Thanks Adrian!

Patch committed r112090

Comment by Aaron Zeckoski (Inactive) [ 06-Sep-2012 ]

Minor tweak for this patch is to define the default in the existing code. Then communicate with stanford.
samigo.answerUploadRepositoryPath=${sakai.home}/samigo/answerUploadRepositoryPath/

Group agrees that warning here is good enough.

Comment by Aaron Zeckoski (Inactive) [ 06-Sep-2012 ]

Minor patch in place and assigned over to Samigo team to review and merge back to 2.9.x

Comment by John Johnston [ 13-Sep-2012 ]

Import tested successfully on Safari 5.1.7, Firefox 15.0.1, Chrome 21.0.1180.89

Comment by Neal Caidin [ 04-Oct-2012 ]

bulk close based on this query - project in (SAM) AND resolution = Fixed AND fixVersion in (13075,13076,13074,12100) AND status = Verified AND "2.9.x Status" in (Resolved, Closed)

Generated at Sat Oct 19 23:16:57 CDT 2019 using Jira 8.0.3#800011-sha1:073e8b433c2c0e389c609c14a045ffa7abaca10d.