Start a new topic

Crushtask Issue @ Wed Jul 23 15:16:12 EEST 2014
I have a CrushTask that is supposed to rename and then move files when certain users upload files. For 2 users this task fails. It's difficult to diagnose as these users only upload once or twice a month. The log from this morning shows:

07/23/2014 10:59:40 AM|Event:PLUGIN Rename and Notify:CrushTask:RenameNotify:
07/23/2014 10:59:40 AM|tasks.Task.:CrushTask items size=3
07/23/2014 11:00:38 AM|Cleaning up old job log file:ypv5_140522033253.log
07/23/2014 11:00:40 AM|Event didn't complete in 60 seconds, leaving thread running...items=3:Event={event_plugin_list=CrushTask:RenameNotify, event_now_cb=false, linkUser=, cc=, event_dir_data=, body=, linkEvent=, id=oKc3Qeeesj, name=Rename and Notify, event_if_list=, bcc=, from=%user_email%, pluginName=CrushTask, event_after_cb=true, subject=Example for on Disconnect:?User %user_name%, event_action_list=(run_plugin), event_if_cb=false, event_always_cb=true, to=, event_after_list=(disconnect_all), event_user_action_list=(upload)}
07/23/2014 11:01:10 AM|tasks.Task.:Event:PLUGIN Rename and Notify
07/23/2014 11:01:10 AM|tasks.Task.:java.lang.Exception: Renamed failed after 90 attempts.
07/23/2014 11:01:10 AM|
07/23/2014 11:01:10 AM|tasks.Task.:tasks.Task.go:142
07/23/2014 11:01:10 AM|tasks.Task.:CrushTask.Start.doTasks:220
07/23/2014 11:01:10 AM|
07/23/2014 11:01:10 AM|tasks.Task.:sun.reflect.GeneratedMethodAccessor2677.invoke:-1
07/23/2014 11:01:10 AM|tasks.Task.:sun.reflect.DelegatingMethodAccessorImpl.invoke:-1
07/23/2014 11:01:10 AM|tasks.Task.:java.lang.reflect.Method.invoke:-1
07/23/2014 11:01:10 AM|tasks.Task.:crushftp.handlers.Common.runPlugin:3805
07/23/2014 11:01:10 AM|tasks.Task.:crushftp.server.Events6.doEventPlugin:910
07/23/2014 11:01:10 AM|tasks.Task.:crushftp.server.Events6$
07/23/2014 11:01:10 AM|
07/23/2014 11:01:45 AM|Server Memory Stats: Max=494.93 MB, Free=435.26 MB

2 files were uploaded, one was renamed and the other was not.

In the user definition the event is set to run after the user disconnects all sessions.

The task consists of:
Rename - New name {stem}_{user_name}{ext} Keep trying for 90 seconds
Move - Destination: {chop_start}{parent_url}{chop_end}ready/{name} other settings at default

It's failing on the Rename so the files are not moved and no notice is generated.

Any ideas on what would cause the initial rename to fail?

spinkb @ Wed Jul 23 15:41:19 EEST 2014
The rename is failing due to a permissions issue on the OS, or the user has the file still in use...and your OS doesn't allow renaming an in use file (windows).

Its one of those two reasons...or the file didn't exist due tot he user renaming it or something...

Ben @ Wed Jul 23 15:48:00 EEST 2014
This last time the user uploaded 2 files, one renamed and one didn't. The job is set to run after the user has disconnected all sessions so I'm not sure why it still would be "in use" unless somehow Crush was holding the file open for some reason.

edit: rechecked the log in the upload process and user is not trying to rename the file after uploading. They upload the 2 files, check the download folder for any files to download and then all sessions appear to disconnect.
spinkb @ Wed Jul 23 15:48:51 EEST 2014
Unlikely CrushFTP holding it open...

Virus scanning software?

Can you manually rename it later on? @ Wed Jul 23 15:49:58 EEST 2014
I can rename the file after the fact, but by then the files have been sitting in the folder for several hours because no email notification was sent.

As far as virus checking, the file that didn't rename is only 1.7Mb in size and contains simple text so I would think by the time Crush made 90 attempts to rename any checking would be long completed...
spinkb @ Wed Jul 23 16:43:00 EEST 2014
Put a wait task before the rename...wait for say 3 minutes, then the rename.

Or rename, on failure, wait 3 minutes, another rename task (not looping back to the other one), if that too fails, then email yourself an email.

rename1 -> move
---on fail: wait 3 minutes -> rename2 -> move
-------------------------------------on fail: email admin
Login to post a comment