Willem Jiang

> 1.版本0.5.0，用的是saga-spring-demo，alpha没有使用状态机 > https://github.com/apache/servicecomb-pack/blob/a89c7cd8b416c9b281fdbe28644cb6b7e2e78f91/omega/omega-context/src/main/java/org/apache/servicecomb/pack/omega/context/CallbackContext.java > 在apply方法中try catch住了cancel方法的异常，但是只打印了log,然后接着执行 sender.send(new TxCompensatedEvent(globalTxId, localTxId, parentTxId, compensationMethod)); > alpha收到TxCompensatedEvent后就更新command状态为dnwn增加sagaEndedEvent就结束事务了。 > 在整个过程中catch住了异常，但是接下来的处理逻辑和没有发生异常时是一样的。这样从数据记录就看不出补偿是否成功。不知道是不是我那里缺少配置造成的还是有其他的处理方式？ CallbackContext 抓住的异常是和回调方法相关的，这些异常有可能和你的配置有关。 因为如果不忽略这样的异常，Alpha下发的命令在下一次执行的时候还是有可能失败，因此通过日志输出方式来处理这样的问题。

从你描述的信息俩看，timeout处理这块的逻辑不太对。 请问你是一个Alpha实例还是多个Alpha实例？

我查了一下代码， 目前对confirm的超时或者错误没有相关的处理，导致Alpha还是会将其认为是一个超时的事务。 这里需要修改的内容是： 如果confirm失败了， 其实这个时候有点尴尬，Alpha要么记录日志，要么调用cancle方法。 还有如果调用cancle方法也失败了，最后也只能记录日志供后续查看了。 因为我们后续会把TCC的数据库实现转换成为状态机的实现，不知道你有没有兴趣一起参与实现。

> alpha端配置了address和serviceId，omega是否都要配置这两个属性，还有address的作用是用来进行grpc调用的吗？如果是，那么serviceId的作用是什么？是否必须配置 Alpha端除了配置主机以及端口信息， 还需要配置实例ID applicationId， 不知道你说的serviceId是不是 applicationId。 在Cluster运行情况，由于我们现在只支持一个Alpha Cluster，所以不需要填写Alpha连接的实例，如果后续出现分片或者要支持多个Alpha Cluster的情况下在Alpha这端就需要配置相关的信息了。 另外Omega端需要配置 ServiceName 和 InstanceId是用来让Alpha区分连接上来的Omega的实例的。

> 我发现omega必须配置alpha address才能发现alpha，如果不配置默认使用localhost:8080，这样的话就必须保证alpha和omega在同一服务器上，但这是不现实的，你们支持omega只配置alpha serviceId就可以发现alpha吗？ 这种情况下还是需要配置服务器注册中心的， 现在Pack支持Consul， Euraka 以及ZooKeeper 做相关的服务发现。

需要检查了一下debug和运行环境的差别， 担心缺了某些依赖。

需要加入这两个依赖 ``` org.apache.servicecomb.pack omega-transport-feign org.apache.servicecomb.pack omega-spring-cloud-eureka-starter ```

docker是用来简化使用的， 如果不用docker，你需要手动启动很多很多服务。 文档那块不清楚你可以先标注出来。

It looks like a classloader issue, can you double check if the the class C is loadable for Service C. If you are using some class enhance tech, it may...

How do you call the service C, Service D from Service A. Are they in different processes?