org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'ŽventoryService' available at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultListableBeanFactory.java:685) ~[spring-beans-5.0.9.RELEASE.jar:5.0.9.RELEASE] at org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(AbstractBeanFactory.java:1210) ~[spring-beans-5.0.9.RELEASE.jar:5.0.9.RELEASE] at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291) ~[spring-beans-5.0.9.RELEASE.jar:5.0.9.RELEASE] at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:204) ~[spring-beans-5.0.9.RELEASE.jar:5.0.9.RELEASE] at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1095) ~[spring-context-5.0.9.RELEASE.jar:5.0.9.RELEASE] at org.dromara.hmily.core.helper.SpringBeanUtils.getByName(SpringBeanUtils.java:72) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.helper.SpringBeanUtils.getBean(SpringBeanUtils.java:64) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.reflect.HmilyReflector.execute(HmilyReflector.java:66) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.reflect.HmilyReflector.executor(HmilyReflector.java:54) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.service.executor.HmilyTransactionExecutor.confirm(HmilyTransactionExecutor.java:149) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.service.handler.StarterHmilyTransactionHandler.lambda$handler$1(StarterHmilyTransactionHandler.java:81) [hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.disruptor.handler.HmilyConsumerTransactionDataHandler.executor(HmilyConsumerTransactionDataHandler.java:28) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.disruptor.handler.HmilyConsumerTransactionDataHandler.executor(HmilyConsumerTransactionDataHandler.java:13) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.disruptor.DisruptorConsumer.onEvent(DisruptorConsumer.java:40) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at org.dromara.hmily.core.disruptor.DisruptorConsumer.onEvent(DisruptorConsumer.java:29) ~[hmily-core-2.0.5-RELEASE.jar:2.0.5-RELEASE] at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:143) ~[disruptor-3.4.0.jar:na] at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_172]

您好，以下是我使用的各个组件的情况：

• jdk: 1.8
• hmily-spring-boot-starter-springcloud: 2.0.5-RELEASE
• spring-cloud: Greenwich.SR2
• Nacos(SpringCloudAlibaba): 0.9.0.RELEASE
• OS: Mac OS X 10.14.6

我按照示例中的代码搭建了 account、stock、order 的服务，在启动的时候报如下错误：

Caused by: java.lang.NullPointerException: null
	at org.dromara.hmily.core.helper.SpringBeanUtils.getBean(SpringBeanUtils.java:62)
	at org.dromara.hmily.core.schedule.HmilyTransactionSelfRecoveryScheduled.onApplicationEvent(HmilyTransactionSelfRecoveryScheduled.java:75)
	at org.dromara.hmily.core.schedule.HmilyTransactionSelfRecoveryScheduled.onApplicationEvent(HmilyTransactionSelfRecoveryScheduled.java:52)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:172)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:165)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:139)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:402)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:408)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:359)
	at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:896)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:552)
	at org.springframework.cloud.context.named.NamedContextFactory.createContext(NamedContextFactory.java:136)
	at org.springframework.cloud.context.named.NamedContextFactory.getContext(NamedContextFactory.java:101)
	at org.springframework.cloud.context.named.NamedContextFactory.getInstance(NamedContextFactory.java:145)
	at org.springframework.cloud.sleuth.instrument.web.client.feign.TraceFeignContext.getInstance(TraceFeignContext.java:46)
	at org.springframework.cloud.openfeign.FeignClientFactoryBean.get(FeignClientFactoryBean.java:220)
	at org.springframework.cloud.openfeign.FeignClientFactoryBean.feign(FeignClientFactoryBean.java:84)
	at org.springframework.cloud.openfeign.FeignClientFactoryBean.getTarget(FeignClientFactoryBean.java:257)
	at org.springframework.cloud.openfeign.FeignClientFactoryBean.getObject(FeignClientFactoryBean.java:247)
	at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:171)
	... 61 common frames omitted

打断点调试后发现是 SpringBeanUtils 类的 bean = cfgContext.getBean(type); 这一行 cfgContext 为 null，这里的静态变量应该是 HmilyTransactionBootstrap#setApplicationContext 设置值的，但是 HmilyTransactionSelfRecoveryScheduled#onApplicationEvent 方法优先执行了，导致 cfgContext 一直是 null 启动无法通过。

这是Hmily目前的中文文档：https://gitee.com/shuaiqiyu/website/tree/master/docs/zh-cn/hmily 英语比较好的小伙伴可以参与进来一起将其翻译为英文。 这是Hmily的官网文档链接：https://dromara.org/website/zh-cn/docs/hmily/index.html

• 翻译任务一

• [x] Hmily的介绍

• [x] 分布式事务相关术语

• [x] 团队介绍

• [x] 常见问题FAQ

• 翻译任务二

• [x] 配置详解

• [x] 本地模式

• [x] Zookeeper配置中心

• [x] Nacos配置中心

• [x] Apollo配置中心

• [x] Etcd配置中心

• [x] Consul配置中心

• 翻译任务三

• [x] 注解详解

• [x] 事务上下文

• [x] Metrics信息

• [x] TCC模式

• [x] TAC模式

• 翻译任务四

• [x] 用户文档-Dubbo用户

• [x] 用户文档-Motan用户

• [x] 用户文档-Spring Cloud用户

• [x] 用户文档-Sofa-RPC用户

• [x] 用户文档-Tars用户

• [x] 用户文档-GRPC用户

• 翻译任务五

• [x] Dubbo快速体验

• [x] Motan快速体验

• [x] Spring Cloud快速体验

• [x] Sofa-RPC快速体验

• [x] Tars快速体验

• [x] GRPC快速体验

• 翻译任务六

• [x] 运维平台-启动admin

• [x] 贡献者指南

• [x] 提交者指南

• [x] 编码规范

• 翻译任务七

• [x] 项目的readme翻译

1. 在hmily-rpc模块下新增 hmily-brpc模块，提供brpc的整合 （rpc传递参数，以及取参数） 结构如下： hmily-rpc ------hmily-brpc

2. 在hmily-demo下，新增对brpc支持的demo实现，结构如下：

hmily-demo ------hmily-demo-brpc-account ------hmily-demo-brpc-inventory ------hmily-demo-brpc-order

完成rpc的调用（可以参考dubbo，motan，sofa-rpc）

2.0.0的版本用hmily-spring-boot-starter-springcloud的话 并且我不是用mongoDB 每次启动都要报错一下 ,如果禁用mongoDB又启动不了 2.0.5的版本用hmily-spring-boot-starter-springcloud的话 用feign自动注入会注入失败 出现直接启动报错 这些都是bug

---->mongoDB报错 com.mongodb.MongoSocketOpenException: Exception opening socket at com.mongodb.connection.SocketStream.open(SocketStream.java:62) at com.mongodb.connection.InternalStreamConnection.open(InternalStreamConnection.java:126) at com.mongodb.connection.DefaultServerMonitor$ServerMonitorRunnable.run(DefaultServerMonitor.java:114) at java.lang.Thread.run(Thread.java:748) Caused by: java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at com.mongodb.connection.SocketStreamHelper.initialize(SocketStreamHelper.java:59) at com.mongodb.connection.SocketStream.open(SocketStream.java:57) ... 3 common frames omitted

------>无法注入报错 Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'orderService': Unsatisfied dependency expressed through field 'webSocketClient'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cn.focus.pay.modular.consumer.webSocketClient': FactoryBean threw exception on object creation; nested exception is java.lang.NullPointerException at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:587) at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:91) at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:373)

SpringCloud 两个服务, 调用者调用Resource-server 的AClient 和BClient. 如图 分布式事务是在调用者和Resource-server 两个服务之间. 当TCC开始生效时, Hmily_RESOURCE_SERVER 里需要生成两条数据,分别是AClient 和BClient 的. 由于是同一个tx_id, 将导致主键冲突,hmily_RESOURCE_SERVER中无相关method 的方法. 事务失效

public class HmilyTransaction {
    private Long transId;
    private List<HmilyParticipant> hmilyParticipants;
}

public class HmilyParticipant {
    private Long participantId;
    private Long transId;
    private Integer status;
}

根据以上定义，个人的理解是：类似于OneToMany的关系。 在redis-repository的实现中（zk类似）： 根据createHmilyTransaction(), 一个HmilyTransaction对象对应redis hash的一个元素，key = HMILY_TRANSACTION_GLOBAL，field = transId，value = HmilyTransaction。 根据createHmilyParticipant(), 一个HmilyParticipant对象也对应redis-hash的元素，key = HMILY_TRANSACTION_PARTICIPANT , field = participantId，value = HmilyParticipant。

之后findByTransId(final Long transId) 通过 HMILY_TRANSACTION_GLOBAL 获取 HmilyTransaction对象。 但是，存在方法updateHmilyParticipantStatus(final Long participantId, final Integer status)，该方法只update了 HMILY_TRANSACTION_PARTICIPANT 中的HmilyParticipant。并未更新 HmilyTransaction 中包含的相同的 HmilyParticipant 对象。

那么，针对同一个participantId 通过 GLOBAL 获取到的status 与 PARTICIPANT 中的状态是否会不一致？ 这种数据不一致是否会造成影响？

当提供者执行完try成功（本地事务提交成功），异步改变自己状态为2失败或者进程被kill 这时提供者状态为1（trying），发起者收到成功返回后执行本地conform成功，调用远程提供者conform报错（远程服务已经kill），此时发起者状态为3，提供者状态为1.（经过压力测试确实存在这样的数据，由于改状态全部是异步修改），只要提供者的schedule先进入发现状态为1的消息，直接进行cancel， 发起者后进入schedule补偿执行conform方法并且调用提供者conform方法。 结果是，提供者B端先执行try->本地执行cancel->远端触发conform，状态不一致 由于异步方法都是异步修改，存在两端状态不一致的情况，应该以发起者为准，又发起者去发起调用。

Hi, in hmily-2.0.0 (hmily-motan module), duplicate classes with the same fully-qualified name org.jboss.netty.bootstrap.ServerBootstrap are included in two different libraries, i.e., io.netty:netty:3.10.5.Final and org.jboss.netty:netty:3.2.5.Final.

According to "first declaration wins" class loading strategy, only this class in org.jboss.netty:netty:3.2.5.Final can be loaded, and that in io.netty:netty:3.10.5.Final will be shadowed.

By further analyzing, your project expects to invoke method <org.jboss.netty.bootstrap.ServerBootstrap: org.jboss.netty.channel.Channel bind(java.net.SocketAddress)> in io.netty:netty:3.10.5.Final. As it has been shadowed, so that this method defined in org.jboss.netty:netty:3.2.5.Final are actually forced to be referenced via the following invocation path:

<org.dromara.hmily.motan.interceptor.MotanHmilyTransactionInterceptor: java.lang.Object interceptor(org.aspectj.lang.ProceedingJoinPoint)> D:\testcase\TestProject\hmily-2.0.0\hmily-motan\target\classes
<org.dromara.hmily.core.service.impl.HmilyTransactionAspectServiceImpl: java.lang.Object invoke(org.dromara.hmily.common.bean.context.HmilyTransactionContext,org.aspectj.lang.ProceedingJoinPoint)> D:\cEnvironment\repository\org\dromara\hmily-core\2.0.0-RELEASE\hmily-core-2.0.0-RELEASE.jar
<org.dromara.hmily.core.service.handler.StarterHmilyTransactionHandler: java.lang.Object handler(org.aspectj.lang.ProceedingJoinPoint,org.dromara.hmily.common.bean.context.HmilyTransactionContext)> D:\cEnvironment\repository\org\dromara\hmily-core\2.0.0-RELEASE\hmily-core-2.0.0-RELEASE.jar
<ch.qos.logback.classic.net.SimpleSocketServer: void run()> D:\cEnvironment\repository\ch\qos\logback\logback-classic\1.2.3\logback-classic-1.2.3.jar
<org.apache.zookeeper.server.quorum.QuorumPeer: void start()> D:\cEnvironment\repository\org\apache\zookeeper\zookeeper\3.4.9\zookeeper-3.4.9.jar
<org.apache.zookeeper.server.NettyServerCnxnFactory: void start()> D:\cEnvironment\repository\org\apache\zookeeper\zookeeper\3.4.9\zookeeper-3.4.9.jar
<org.jboss.netty.bootstrap.ServerBootstrap: org.jboss.netty.channel.Channel bind(java.net.SocketAddress)>

Although both of these two conflicting classes contain the referenced methods (with the same signature), they have different implementations. This issue will not lead to runtime crashes, but it can introduce inconsistent semantic hehavior by changing the control flows and data flows.

Workaround solution: The easy way to workaround the problem is reversing the declaration order of these two libraries in pom file. Then, according to "first declaration wins" class loading strategy, class org.jboss.netty.bootstrap.ServerBootstrap in io.netty:netty:3.10.5.Final can be loaded (the version that ninja expects to reference by static analysis). This fix will not affect other libraries or class, except the above duplicate class.

Dependency tree----

[INFO] --- maven-dependency-plugin:3.0.2:tree (default-cli) @ hmily-motan --- [INFO] org.dromara:hmily-motan:jar:2.0.0-RELEASE … [INFO] +- com.weibo:motan-springsupport:jar:1.0.0:compile [INFO] +- com.weibo:motan-transport-netty:jar:1.0.0:compile [INFO] | - org.jboss.netty:netty:jar:3.2.5.Final:compile [INFO] - org.dromara:hmily-core:jar:2.0.0-RELEASE:compile [INFO] +- org.dromara:hmily-common:jar:2.0.0-RELEASE:compile [INFO] | +- ch.qos.logback:logback-core:jar:1.2.3:compile [INFO] | +- ch.qos.logback:logback-classic:jar:1.2.3:compile [INFO] | +- com.google.code.gson:gson:jar:2.6.2:compile [INFO] | +- com.squareup.okhttp3:okhttp:jar:3.7.0:compile [INFO] | | - com.squareup.okio:okio:jar:1.12.0:compile [INFO] | +- redis.clients:jedis:jar:2.9.0:compile [INFO] | | - org.apache.commons:commons-pool2:jar:2.5.0:compile [INFO] | +- org.projectlombok:lombok:jar:1.16.14:compile [INFO] | +- com.esotericsoftware:kryo-shaded:jar:4.0.0:compile [INFO] | | +- com.esotericsoftware:minlog:jar:1.3.0:compile [INFO] | | - org.objenesis:objenesis:jar:2.2:compile [INFO] | +- com.dyuproject.protostuff:protostuff-core:jar:1.0.8:compile [INFO] | | - com.dyuproject.protostuff:protostuff-api:jar:1.0.8:compile [INFO] | +- com.dyuproject.protostuff:protostuff-runtime:jar:1.0.8:compile [INFO] | | - com.dyuproject.protostuff:protostuff-collectionschema:jar:1.0.8:compile [INFO] | - org.mongodb:mongo-java-driver:jar:3.5.0:compile [INFO] +- org.dromara:hmily-annotation:jar:2.0.0-RELEASE:compile [INFO] +- org.springframework:spring-jdbc:jar:5.0.7.RELEASE:compile [INFO] | +- org.springframework:spring-beans:jar:5.0.7.RELEASE:compile [INFO] | +- org.springframework:spring-core:jar:5.0.7.RELEASE:compile [INFO] | | - org.springframework:spring-jcl:jar:5.0.7.RELEASE:compile [INFO] | - org.springframework:spring-tx:jar:5.0.7.RELEASE:compile [INFO] +- com.zaxxer:HikariCP:jar:3.2.0:compile [INFO] +- org.springframework.data:spring-data-mongodb:jar:2.0.8.RELEASE:compile [INFO] | +- org.springframework:spring-context:jar:5.0.7.RELEASE:compile [INFO] | | - org.springframework:spring-aop:jar:5.0.7.RELEASE:compile [INFO] | +- org.springframework:spring-expression:jar:5.0.7.RELEASE:compile [INFO] | - org.springframework.data:spring-data-commons:jar:2.0.7.RELEASE:compile [INFO] +- commons-beanutils:commons-beanutils:jar:1.9.2:compile [INFO] | - commons-collections:commons-collections:jar:3.2.1:compile [INFO] +- org.aspectj:aspectjweaver:jar:1.8.9:compile [INFO] +- org.apache.zookeeper:zookeeper:jar:3.4.9:compile [INFO] | +- jline:jline:jar:0.9.94:compile [INFO] | - io.netty:netty:jar:3.10.5.Final:compile [INFO] - com.lmax:disruptor:jar:3.4.0:compile

这里假设是发起者发起重试confirm，此时我有发起者的集群，这时他们都会去发起重试，虽然代码里有乐观锁机制保证了最大重试次数，但是如果机器A修改retrycount后，发起confirm，机器B仅跟着修改retrycount，发起confirm。
若业务没有幂等处理，这样就会导致confirm执行两次，所以需要用户保证业务的confirm和cancel的幂等吧？

背景： 1、按这个：https://github.com/yu199195/hmily/wiki/Dubbo-User-Guide 要求进行配置完成； 2、项目框架是spring MVC（4.3.7），dubbo（2.5.6）；

问题： 1、没有报错信息，进不了@Tcc表示的方法，service的句柄正常，但是最后报的是空指针，如果去掉@Tcc注解就可以使用 2、AOP已经生效：

Describe the bug

A 调用 B，B系统接收到A的请求正在执行，此时A系统宕机，后续A系统恢复运行，A B事物都没有进行cancel，也没有confirm。

下面是mysql中存储的事务日志：

发起者： | trans_id | ** app_name** | status | trans_type | retry | version | create_time | update_time | | --- | --- | --- | --- | --- | --- | --- | --- | | -4.18837E+18 | mid-trade | 0 | TCC | 0 | 1 | ######## | ######## |

参与者： | participant_id | participant_ref_id | trans_id | trans_type | status | app_name | role | retry | target_class | target_method | confirm_method | cancel_method | confirm_invocation | cancel_invocation | version | create_time | update_time | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | -4.18837E+18 | | -4.188E+18 | TCC | 0 | mid-trade | 1 | 0 | xx | applyPay | applyPayConfirm | applyPayCancel | xx | xx | 1 | | | | -4.18837E+18 | | -4.188E+18 | TCC | 8 | mid-account | 3 | 11 | xx | trade | tradeConfirm | tradeCancel | xx | xx | 12 | | |

Environment

• hmily version(s): [ 2.1.1 ]

服务实现端一直报如下错误： com.google.gson.JsonSyntaxException: com.google.gson.stream.MalformedJsonException: Expected ':' at line 1 column 49 path $.participantId

HmilyFeignInterceptor在对事务信息转为json 设置到 请求头里面时json串因为没有UrlEncode被当成模板解析了，导致后面的服务再接收时，json串缺失数据了。 https://github.com/spring-cloud/spring-cloud-openfeign/issues/711