DEA扩展-讨论5_15

DEA-6-4

关于CF平台的扩展

首先，判断一个构件能否更新，需要判断该构件是否被其它构件依赖，以及该构件是否正在请求其它构件。

因此，我们将一次完整的请求调用抽象成会话（事务）的概念，并为该会话（事务）添加标识，即事务id。

CF支持动态更新所要支持的服务有：

首先需要一个拦截器，拦截进入构件和出构件的请求。（一般，出构件的请求不好拦截）
因此，我们在每次进入构件的时候，拦截请求，这个可以在router中完成。

CF提供一个TM Logger服务，记录所有的事务信息

其次，我们还需要知道构件的具体运行过程，包括事务中事务方法的开始，对其它方法的调用，事务依赖的变化，事务方法的结束。

这个是由插装代码完成的，在事务方法开始时，通知TxDepMonitor，txSTart
在第一次调用其它构件方法时，通知TxDepMonitor.FirstRequest
在完成对其它构件方法调用时，通知TxDepMonitor.DependencesChanged
在事务方法完成时，通知TxDepMonitor，TxEnd

更新时，维护依赖信息，ondemand service

关于请求的拦截，如果该请求是一个被标记过事务信息的请求，那么不需要拦截

如何知道是否被标记过事务请求？需要在请求头上加入标记。

在tuscany中，对其它构件提供的方法进行调用时，直接提供一个调用接口，并直接调用、
tuscany平台会根据composite的reference端提供的绑定uri，将方法调用转为一个Http Post请求，how？

CF平台可以提供一个broker，通过对代码的插装，在请求头加入msg


----------
tuscany的代理，确实太复杂，裸看代码，没什么头绪


----------
关于主流的PaaS平台，winAzure，heroku，GAE，
对于动态更新的支持

关于PaaS的论文


----------
部署在云平台上的应用，更应该支持动态更新?why
  因为应用的功能的增加和完善，更新是不可避免的。而云平台的应用，由于已经部署到云端，因此几乎随时都有用户在使用它。而会更新部署在云端的应用，会导致正在使用该应用的用户丢失请求。因此动态更新显得尤为重要。也就是说，在不停止当前应用的前提下，更新部署到云端的应用。并且能够保证更新前后的一致性。更新前的请求都交由旧版本的应用处理，而更新后的新请求，则交给新版本的应用处理。并且当旧版本的应用请求都处理结束后，将旧版本删除。


----------

call调用hello时，调用call.txLifecycleMgr.startRemoteSubTx

在hello结束的时候，通知parent，调用endRemotSubTx

done


----------
todo:
通过测试papa---call---hello在ondemand后，接收到请求，维护create_future边，来判断更新请求是否正确。
先看执行结果

done

----------


FirstRequest，第一次请求远程方法的时候，会通知txDepMonitor。
以后再调用auth、db时，只会通知DepdencesChanged


----------
关于freeness策略和拦截器问题

1 waiting好像什么都不做
2 blocking，在新请求到达时，检查请求中是否带有根事务T，而T属于oldRootTx
如果是，则说明这个请求的根事务过去有，不拦截，否则拦截

3 version-consistency？


----------
在txLifecycleMgr中加入了initLocalSubTx和endLocalSubTx.
测试正确，在DEA上再次运行多个请求，同时更新应用试试


----------
如果TxEnd先结束了，那会删除txCtx，以及local边等等。
那么，发消息，是同步的？看来应该是相关的！

加入同步和异步消息，等一下，测试看看

无奈啊，java传消息，比ruby快，不得已，让txEnd向DEA传消息的时候，sleep(1s)
hello的txStart也sleep(1s)

现在好像初步没有问题了。
不对，刚刚只是访问了hello,加了延迟之后，多个call访问也正确了。


----------
下面是添加拦截器，在instance--->router注册时，如果有oldRootTxs，则注册到路由器。

修改instance.rb的同时，在router_client.rb中，生成instance_request时，加入"roots"关键字。
主要是修改router代码，包括在registry.go中加入

----------
关于做动态更新服务：
像数据库服务一样，将更新做成动态更新服务。
如果需要支持动态更新服务，那么，用户代码也相应的需要做一定的修改。
可能就不需要代码插入，而是由用户代码去通知具体的DEA关于事务的变化。

cf create-user-provided-service
cf cups repo-service -p "host,port,admin,password"
居然不行？
cf-vagrant-installer现在不支持服务

----------
router的拦截器。
还是做实验吧，拦截器，分发：
app头部可以加一个parentTx标记，还是标记rootTx吧

router维护oldRoot根事务
当记录的instance状态为normal、valid、free、updating、updated

如何在router标识请求的新、旧版本？？？？
何时删除旧版本应用？？？？当router的oldRootTx集合为空的时候？


如何判断router到底将请求转发给旧版本的url，还是新版本的url？


----------
call和hello的send版本不太一样，以call的版本为基准


----------
部署新应用在接收到update请求时，就可以进行了。这里一直很奇怪，卡死？

现在的问题是，部署新应用需要放在新线程中完成？设置标志位？

command(`cf push`)
system(`cf push`)
因为system(cf push) ，导致dea挂了？？？？
改回command？

----------


###TODO，关于FirstRequest。应该每次向其它构件发起请求的时候，都会去startRemote等等。

> Written with [StackEdit](https://stackedit.io/).