博文

目前显示的是 五月, 2013的博文

发现了google-api-java-clien的一个BUG

今天我用google-api-java-client做基于servlet的oauth授权流程,但是遇到了一个奇怪的异常:java.lang.ClassCastException: com.google.api.client.auth.oauth2.AuthorizationCodeResponseUrl cannot be cast to com.google.api.client.auth.oauth2.AuthorizationCodeRequestUrl
com.google.api.client.auth.oauth2.AuthorizationCodeResponseUrl.set(AuthorizationCodeResponseUrl.java:222)
com.google.api.client.auth.oauth2.AuthorizationCodeResponseUrl.set(AuthorizationCodeResponseUrl.java:58)
com.google.api.client.http.UrlEncodedParser.parse(UrlEncodedParser.java:182)
com.google.api.client.http.UrlEncodedParser.parse(UrlEncodedParser.java:96)
com.google.api.client.http.GenericUrl.\(GenericUrl.java:153)
com.google.api.client.http.GenericUrl.\(GenericUrl.java:117)
com.google.api.client.http.GenericUrl.\(GenericUrl.java:106)
com.google.api.client.auth.oauth2.AuthorizationCodeResponseUrl.\(AuthorizationCodeResponseUrl.java:99)
com.google.api.client.extensions.servlet.auth.oauth2.AbstractAuthorizationCodeCallbackServlet.doGet(AbstractAuthoriz…

Hadoop Filesystem 多次close的问题

今天我犯了一个BUG。在我读写文件的时候,Hadoop抛异常说文件系统已经关闭。2013-05-20 17:39:00,153 ERROR com.sunchangming.searchlog.CopyAppLogs: err on 2013051918_api_access_65.gz
java.io.IOException: Filesystem closed
at org.apache.hadoop.hdfs.DFSClient.checkOpen(DFSClient.java:319)
at org.apache.hadoop.hdfs.DFSClient.getFileInfo(DFSClient.java:1026)
at org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:524)
at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:768)
at com.sunchangming.searchlog.CopyAppLogs.copyFile(CopyAppLogs.java:51)
at com.sunchangming.searchlog.CopyAppLogs.access$000(CopyAppLogs.java:18)
at com.sunchangming.searchlog.CopyAppLogs$1.run(CopyAppLogs.java:194)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concur…

printf简直是个地狱

今天我在spdylay这个项目中发现一个小BUG:voidprint_timer(){ timeval tv; get_timer(&tv); printf("%s[%3ld.%03ld]%s", ansi_esc("\033[33m"), tv.tv_sec, tv.tv_usec/1000, ansi_escend()); } 其中timeval的定义如下:struct timeval { time_t tv_sec; /* seconds since Jan. 1, 1970 */ suseconds_t tv_usec; /* and microseconds */ }; 这其中的问题是,suseconds_t到底是什么类型?长度是多少?很不幸。在不同的OS下不同。在Cent OS 6下,它是8字节的long,在Mac OS X 10.8下,它是4字节的int。于是printf很可能就会读越界。

不要再使用Chrome浏览器的--enable-npn选项了

网上有很多过时的教程,教你怎么通过命令行的--enable-npn选项打开chrome的spdy协议功能。但是那些教程真的out of date了。其实什么都不用加,新版本的chrome浏览器已经自动打开spdy了。目前chrome浏览器(version 26)主要有这么几个spdy相关的开关:--enable-spdy4a1: 打开SPDY/4 alpha 1的支持,这只是一个临时性的测试开关。--enable-npn: 通过NPN的方式打开对SPDY/2的支持,但是禁用SPDY/3。--use-spdy: 这个不是用来启用SPDY的,而是通过后面跟的一系列逗号分割的选项来设置SPDY的参数。水很深,不细说!所以加了--enable-npn,反而是禁用了spdy/3。不要哇!