2014_3_8_CF_gorouter

2014_3_12_CF部署sessoin

测试gorouter对**sticky session**的维护

首先启动两个DEA实例


warden启动成功后，启动dea，file-server，directory-server。

1进入vagrant/warden2/warden目录
执行sudo bundle exec rake warden:start[config/linux.yml]

> rbenc:version '1.9.3' is not installed
如果遇到这个bug，修改.ruby_version即可

2 进入/vagrant/dea_ng2
bin/dea config/dea.yml

2 进入/vagrant/dea_ng2目录
sudo go/bin/runner -conf config/dea.yml

3 进入/vagrant/dea_ng2目录
bundle exec spec/bin/file_server.rb

4进入test/hello-jsonrpc目录
部署tuscany应用，两个实例

部署失败？
"caught exception script exited with status 127"

原因是jboss占了80端口？因为apache把请求都转发给jboss了。
关闭apache的转发功能，我将mods-available中的jk.conf和jk.load移走了，不行
因为mods-enable中有对jk.conf和jk.load的link。


mods-enabled的jk.conf链接到../mods-available/jk.conf
mods-enabled的jk.load链接到../mods-available/jk.load
尝试将这两个都删除。

靠，居然不小心将这两个文件删了。。。

还有sites-enabled中的000-default的转发，给他注释了。

# 修改apache2.conf

看来是不行 了，卸载apache2吧

shit...

重装apache后，可以了

带session的应用，tuscany的话。。。
？

web应用？



gorouter在proxy.go的lookup函数中，会检查sticky session。
  找到请求中的host，然后对于该请求，检查是否有StickyCookieKey，如果有的话，直接从中获取sticky，再通过uri和sticky.value的组合找到请求的backend。这里稍微解释一下StickyCookieKey的作用。一旦一个请求中含有该**cookie**，而且能被解析到相应的uri和sticky值，也就是说这个请求，希望被处理的时候，能继续被上次处理过这个用户发出的请求的app instance上，这样的话，可以避免一些不必要的数据冲突等，或者减少DEA中app instance的负载。**如果没有找到cookie的话**，那么proxy就老老实实通过host来找到相应的ip：port，如果一个host有多个instance实例的话，proxy会通过某种策略（随机）来决策由哪个Instance来服务。
  
  如果是多个实例池的情况，即使找不到这样的cookie，我们也需要在上次访问该url的时候，将cookie缓存。缓存到router节点所在的主机？此时，如果找不到cookie，从缓存的地方，读取相应的cookie。但是数据如何有cache，并且存放在DEA所在节点的主机上，那么，gorouter需要做到备份这些cache？
  
  


## ----------------------------------------------------------------------------

下面就是考虑CF对stciky session的支持。
首先，来验证，在CF上部署带有session的java servlet或者jsp
创建testTomcat的web应用，将用户输入的数据保存为cookie

会话跟踪: 
请求1： 客户将注册数据传给服务器，服务器给用户返回数据，要求确认
请求2： 客户确认这些数据，并重新提交给服务器。

部署tomcat应用时，保存，undefined method 'fetch' for "flag=false flag2=true"
这个错误以前出现过。

staging_plugin.rb第110行。
buildpack.rb79行，info.fetch("default_process_type")
 可是java_web.rb中，不是有defult_process_types么
 
 “web” => "./bin/catalina.sh run"

   在CF上运行时，需要将servelt前面的应用名去掉。因为CF上传时，没有应用名。
   1 CookieRegistration.html的表单里
   2 servlet中doGet函数中，会定位到post， 
   
   又干了已经SB的事情，端口冲突啊，显然会按照之前的那个转发啊，真傻。。。