2014/04/10
2014/03/21
FileDropJS 的 Java servier-side
最近要做drop file upload的系統,經過挑選,選擇了一個較light-weight的FileDrop (filedropjs.org)
不過它只有提供PHP server-side程式可參考,找了老半天,沒有看到Java的solution,於是只好自己來研究一下了
還好花一天的工就完成,在這裡做個記錄
不過它只有提供PHP server-side程式可參考,找了老半天,沒有看到Java的solution,於是只好自己來研究一下了
還好花一天的工就完成,在這裡做個記錄
protected void process(HttpServletRequest request, HttpServletResponse response) throws IOException {
PrintWriter writer = response.getWriter();
JSONObject obj = new JSONObject();
try {
saveRawDataToFile(request); // file upload by raw request
obj.put(AbstractCommand.R_SUCCESS, true);
obj.put(AbstractCommand.R_MSG, "upload completed");
} catch (IOException e) {
obj.put(AbstractCommand.R_SUCCESS, false);
obj.put(AbstractCommand.R_MSG, e.getMessage());
} finally {
writer.println(obj.toString());
writer.flush();
}
}
protected void saveRawDataToFile(HttpServletRequest request) throws IOException {
String filename = request.getParameter("img") + ".png";
String outputFile = uploadPath + File.separator + filename;
InputStream in=request.getInputStream();
int size=request.getContentLength();
try {
OutputStream out=new FileOutputStream(outputFile);
byte[] chunk= new byte[size];
in.read(chunk);
out.write(chunk,0,size);
out.close();
} catch (Exception e) {
e.printStackTrace(System.out);
} finally {
in.close();
}
}
2014/02/17
2014/02/10
crontab的怪問題
上週總公司的PM告訴我,過年後回來開工,發現CVS server掛點,經過一天的搶救,才把CVS給救回來。
台中辦公室也有Subversion server,想說也該趁這機會建立自動備份機制,尤其這server是架在有點老舊的機器(應該快十年了吧,Ubuntu 8.10)上,哪天鬧脾氣,真的會欲哭無累。
SVN上總共有三十多個repositories。寫了幾個shell scripts,讓這備份機制可以一一將每個repository備份出來,經壓縮後,以ftp上傳到另一部主機。執行一下,OK,順利備份到ftp server了。接下來,只要設定一下crontab,這shell script可以定時執行就完成了。
不過,莫非定律果然無所不在--"Anything that can go wrong will go wrong.",想說老天怎麼會這麼善待我。用cron跑的,就只有備份出七個repositories而已。
怪了,怎麼會有問題,手動執行不是好好的嗎?
一個一個來查查...
權限有問題...應該不是,不然不會還完成七個
先把ftp上傳的功能關掉...還是一樣
會不會是備份出來檔案佔太多空間,改成dump一個就上傳一個,上傳完就砍掉local的檔案...還是一樣
...
黔驢技窮,不過這樣盲目亂猜太不科學了,應該要想辦法看一下執行過程的輸出,再對症下藥
把crontab裡的command由
這樣執行時,就可以看到stdout與stderr的內容,才能避免瞎子摸象,用較有效率的方式解決問題
設定的時間一到,script開始執行,svn repository開始備份上傳了
一個、兩個、三個...六個、七個
嗯,準備看看cron.out能不能給我點靈感了
八個、九個、十個...
咦,這次怎麼沒有停下來
三十、三十一、三十二... 竟然全部備份並上傳完了
這是怎麼回事?
再把crontab的command改回原來的樣子,還是完成七個備份就停掉了
再把stdout, stderr的output加上去,備份功能又正常了
完全不解這是怎麼一回事!找了老半天,也沒看到有這方面的討論或敘述。有人遇過這樣的情形嗎?
不過至少auto-backup機制是能正常工作了。至於為什麼會這樣?再來慢慢找解答了。
台中辦公室也有Subversion server,想說也該趁這機會建立自動備份機制,尤其這server是架在有點老舊的機器(應該快十年了吧,Ubuntu 8.10)上,哪天鬧脾氣,真的會欲哭無累。
SVN上總共有三十多個repositories。寫了幾個shell scripts,讓這備份機制可以一一將每個repository備份出來,經壓縮後,以ftp上傳到另一部主機。執行一下,OK,順利備份到ftp server了。接下來,只要設定一下crontab,這shell script可以定時執行就完成了。
不過,莫非定律果然無所不在--"Anything that can go wrong will go wrong.",想說老天怎麼會這麼善待我。用cron跑的,就只有備份出七個repositories而已。
怪了,怎麼會有問題,手動執行不是好好的嗎?
一個一個來查查...
權限有問題...應該不是,不然不會還完成七個
先把ftp上傳的功能關掉...還是一樣
會不會是備份出來檔案佔太多空間,改成dump一個就上傳一個,上傳完就砍掉local的檔案...還是一樣
...
黔驢技窮,不過這樣盲目亂猜太不科學了,應該要想辦法看一下執行過程的輸出,再對症下藥
把crontab裡的command由
xxxxx.sh
改成 xxxxx.sh > /home/yy/cron.out 2>&1
這樣執行時,就可以看到stdout與stderr的內容,才能避免瞎子摸象,用較有效率的方式解決問題
設定的時間一到,script開始執行,svn repository開始備份上傳了
一個、兩個、三個...六個、七個
嗯,準備看看cron.out能不能給我點靈感了
八個、九個、十個...
咦,這次怎麼沒有停下來
三十、三十一、三十二... 竟然全部備份並上傳完了
這是怎麼回事?
再把crontab的command改回原來的樣子,還是完成七個備份就停掉了
再把stdout, stderr的output加上去,備份功能又正常了
完全不解這是怎麼一回事!找了老半天,也沒看到有這方面的討論或敘述。有人遇過這樣的情形嗎?
不過至少auto-backup機制是能正常工作了。至於為什麼會這樣?再來慢慢找解答了。
訂閱:
文章 (Atom)