帐前卒专栏

今天解决了上传大文件问题。这个问题对于简单的web程序基本是不用关注的。不过需要考虑http超时和socket超时等情况。对于nginx代理跳转的web程序，需要在nginx中设置client_max_body_size 和 proxy_read_timeout这两个地方。前一个参数是http body size,例如你要上传10M的文件，你这里需要设置11M或者更大，因为http body中不光有文件的二进制信息。后者是设置proxy server与后端server的连接后等待返回的时间。例如后面使用的是JBoss那就是与JBOSS的连接。

确定问题比较容易。如果一个请求发生，但是后端Server没有打印access log.那就说明请求还没有到后端server，需要检查代理服务器的设置。如果请求写入access log,但是没有被server后端的webapp打印出log,一般说明在后端的server处挂掉，需要检查后端server的相应配置。当然也可能是webapp自己直接做了限制，例如设置如下类的参数

1

org.springframework.web.multipart.commons.CommonsMultipartResolver

这里设置后会导致在doFilter()之后parseRequest时挂掉。如果看到报类似SizeLimit exception或者 max upload file exception,大概就是这里的问题。

最后要检测app代码中是否也有这些限制。以及检查client端socket timeout等情况。以下代码是针对client socket提前超时设置的。

1
2
3
4

HttpParams params = new BasicHttpParams();
HttpConnectionHttpParams.setConnectionTimeout(params,60000); // 连接超时1分钟
HttpConnectionHttpParams.setSoTimeout(params, 60000); // socket 读取写入超时
DefaultHttpClient client = new DefaultHttpClient(params);

Server1.6版本上线，水文与经验总结。

http://chillyc.info/blog/2012/05/11/server-1-dot-6-shang-xian/

不理解cookie的话，那还是相当诡异的…

http://chillyc.info/blog/2012/05/11/cookie/

Cookie的特性：

• 首先分为3种cookie:
  1. 持久化cookie(persist cookie), 这种cookie有过期时间, 关掉浏览器还存在。
  2. 会话cookie(session cookie), 这种cookie没有过期时间，关掉浏览器就消失。
  3. 要被删除的cookie(deleted cookie). 这种cookie到达请求方就立即失效了。不会再带回服务器端。
• Cookie的domain一定要对。例如发送给note.youdao.com的cookie, domain可以是.note.youdao.com, 可以是.youdao.com.但是最好是.note.youdao.com, 否则有可能给其他的应用带去不必要的cookie, 增大传输量。
• Cookie的path一定要对，如果在生成cookie时没有指明，那就是那个页面的当前路径。例如note.youdao.com/web/x.html 生成了cookie, 那路径就是/web, 再访问note.youdao.com/时，这个cookie不会被带上。只有/web以及/web的子路径可以得到该cookie.所以一般cookie的path设置为"/".
• Cookie是否是HTTP ONLY.这个对JS很重要。其实就是SET-COOKIE: header中加入了httponly的字段。但是HttpOnly的cookie, JS是拿不到的。在一定程度上保证安全。
• 永久cookie是跨进程的。当然chrome做到session cookie也跨进程(跨chrome进程)。永久cookie可以跨所有的进程。例如客户端用A帐号访问，web端用B帐号访问。客户端的永久cookie会带到web访问中。
• JAVA的HttpClient或者其他httpClient库发送cookie到server时不会带上HTTPOnly或者domain信息，因为他们只有对的domain才会发送cookie. 但是如果server要做抹除客户端cookie的事情，那就必须在返回消息中发送除cookie value和过期时间不一致，其他都要一致的cookie才行。否则达不到抹除的目的。

就先写到这里。

今天server端上线，自己负责的两个server上线，一个更新了依赖，另外一个FIX了一个稳定性问题。当然变化最大的server很快就会上线。话说本产品的最大竞争对手入住中国，本以为有啥大事发生，后来发现只改了个名字。搞出一个中国公司这事情还要瞒着zzzz

然后今天晚上发现微博里好多活动的人。都有做server的潜质呀。

个人感觉还是不要加什么硬类型，什么硬编码，什么字段。map存储是扩展王道。当然弱类型肯定速度慢，但如果这里速度慢不是瓶颈，那不算什么问题。

这周解决的问题颇多，后来发现是自己遗留下的问题颇多。当初的设计想想都是很奇葩的。现在只能愈加奇葩。下个版本重构一下，遗留的能fix的就fix吧。

答辩终于结束，心里压力顿时小许多。filter呀filter, 整合入common吧～

明早倒休…要睡到中午~~~~

好吧，有空出篇技术贴，现在写blog太水了。

Server上线还是没有一次成功。又出了各种小问题。这次主要是由于配置文件线上和milestone不同。以后要diff一下milestone的配置文件和online的配置文件。确认后再上线。

原来的app好好的，结果爆出mismatch url error。

详见. http://chillyc.info/blog/2012/04/26/sina-oauth2/

万恶的新浪呀～～～今天本来事情多，结果新浪Oauth2.0接口突然有变化。导致新浪用户无法使用有道云笔记登录，登录就会有mismatch url error。于是今天做hot fix. 一时找不出问题时，客户端登录不上去，但是web可以正常使用。然后经大师兄点拨，对比了一下两个访问新浪的url,终于发现了不同。原因在于某个新浪小白程序猿写程序出了bug。我的callback地址是四级域名（xx.xx.youdao.com）而新浪现在的接口即使绑定了域名，还是只支持三级域名(xx.youdao.com). 以前新浪的小白程序猿还写出来仅接受一个url参数的神奇程序，当然出现这个情况也在意料之中。我时常在想写新浪微博和写新浪微博openAPI的一定不是同一批人。最主要的是新浪更新或者新浪自己挂掉从来不通知开发者。这让人相当费解。只有不要传播谣言啥的专门给开发者发信…他们真有趣。

知道了原因，首先做hot fix.让新浪那边改，那难比登天呀。做第三方这事情还是QQ做得好些。Hot fix比较恶心，不推荐大家学习。虽然只改了一句code，但是是硬编码。Hot Fix之后，所有的客户端就能正常登录了。但是有道云笔记的页面会最终说…其实你没有认证成功的…但是客户端的确是活着好好的。这是为啥…上了趟厕所，灵感来了。有道server完成了跳转，但是因为cookie的domain和callback的域名不一致。所以那个最终页面看到没有带来cookie呀，那肯定登录失败了。但是cookie被client端很好接收。所以也就可以完成登录和获取数据。这就是为啥登录失败了，但是客户端还活着好好的。

然后继续做Hot FIX.后来发现自己编来编去，还是太丑陋。直接叫运维做了一个跳转…然后客户端就活得好好的了。也不会出现登录失败页了。

今天大事小事都赶到一起了。做了一个TTT，本以为写得概括大家就都能听懂，结果大家都听得很朦胧。以后写ppt还是要写细致一些，还要写挑战和为什么要做这件事。嗯嗯，下次会更好…这又让我想到写论文…话说敏姐的致谢中大部分都是在赞美导师…这一定是怕不让毕业…

最近碰到了svn merge之后，再使用svn diff产生出来的patch中缺少某些文件的信息。后来发现了原因。使用svn st查看那些文件信息，类似于:

1
2
3

A       src/aa.c
A   +   src/bb.c
M       src/cc.c

这样输出的patch中，aa.c是信息是都有的。cc.c也是有的。但是bb.c的信息不存在。主要是存在那个+. +的意思是这些文件存在于提交历史中，所以该文件不能再次被diff.但是为什么会存在于提交历史中，这个我就不知道了。
下面是教你如何去掉+.
使用下面的脚本会方便的去掉各个文件的+,对于目录的+是不能去掉的.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#!/bin/sh
plus_file=`svn st | grep "^A" | grep "+" | cut -d" " -f6`
for i in $plus_file; do
        if [ -d $i ]; then
                echo "skip $i"
        else
                cp ${i} ${i}.back;
                echo $i;
                svn revert $i;
                mv ${i}.back ${i};
                svn add $i;
        fi

done;

1
2
3
4
5

上面脚本的工作原理是:
cp src/bb.c src/bb.c.back
svn revert src/bb.c
mv src/bb.c.back src/bb.c
svn add src/bb.c

这样所有的A +状态就变为了A。这样再使用svn diff就可以得到完整的diff信息。如果有想法还可以处理一下文件夹。不过review code时，文件夹的意义并不大，所以就没有处理。这里顺便感谢下巧大牛。

今天晚上…或者说今天早上。反正是跨天的.有道云笔记1.5版本正式上线。开始时数据转换花了很长时间。后面基本没有出现什么大问题，主要是id不统一。整到两点钟才算正式搞好。明天早上就不准备去上班了.困…还是把这篇blog写完吧。

####问题：

1. 其实测试环境下，还是不能测试出所有到问题。因为和线上的配置不一样。
2. 其实组内改动什么设计问题，可能牵扯到几个人，但是做设计或者真正写代码的时候，其实不知道牵扯到谁。
3. web页面的文字链.其实没有提前做好。不知道为什么UI总是在临上线的时候才有。
4. 技术先导的project,再让PM来设计.真的是比较痛苦。

####新的功能：

1. 客户端新浪微博帐号登录。其实根据现在的涉及还是有些bug的。比如打开两个授权页面，第一个页面其实已经不能再用来登录了。但是用户输入用户名密码还是会授权成功。至于为什么…我不告诉你～
2. 锁屏…离线登录态…还有啥就不知道了。
3. server端的设计有改动。
4. 。。。。。

####好了…该去睡觉了。
另外今天上线的是有道云笔记1.5正式版…比官方稿件快7-8个小时…
另外地址是有道云笔记1.5

今天把程序从windows上迁移到了linux上。主要遇到到问题是: makeFile, lib库, compile error, 编码 encoding.
####make file
这里其实可以使用eclipse中到cdt插件，然后就可以从eclipse中写c++。挺方便的，同时也解决了make file的问题。因为创建一个c++ 或者 c project，eclipse会自动创建一系列的makefile文件。所以让make file步骤简单无比。
####lib库和include库
这里真的要注意/usr/include和/usr/lib中是否有你想要到文件。当然如果你是纯c代码，可以尝试下只使用/usr/include/c. 当如除了-L libpath, 还有-llibname, 这里的libname其实是libXXXX.so中的XXXX. 不过如果不会写，这里还是会费些劲。还有include路径要使用-I,每一个路径前都要有一个-I. 另外还要在eclipse run configurate中的environment中填入LD_LIBRARY_PATH,这个是你要调用的lib库（这个lib库如果不在/usr/lib中，那么就要手工将路径填入到LD_LIBRARY_PATH变量里）。并且在.bashrc中写：

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:your_lib_path

####编码
因为windows上最常用到中文编码是GBK,而文件编码最常用到是utf-16el.这里最有可能会出错。在eclipse中或者gcc直接编译，都最好转换为UTF-8编码。文件也需要是UTF-8的编码。否则就会报"程序有游离的XXX, 忽略空字符"等诡异的错误。详见解决方法
####compile error
这个可能就多种多样了。不过有c/c++基础的，应该大部分都可以搞定了。

如果使用eclipse, 直接build project就可以编译成功。然后找到main函数run就可以了。