本文目录一览:
cxf 如何获取异常报文 在代码中是怎么实现的
1. 单独建立线程池,线程池中的所有工作线程从线程池任务队列中读取任务,启动SOAP报文下发工作。
2. 建立连接池,线程池中线程从连接池获取一个连接将SOAP报文下发到网元上。
3. 其他线程:SOAP报文读取线程,将生成的SOAP报文文件映射到内存文件,每次读取1w条数据到SOAP报文下发队列,SOAP下发队列数据结构进行
封装,添加信号量,每次数据push_back一条信号量递增
SOAP报文下发线程,独立的线程从SOAP报文下发队列中取数据,等待下发队列的信号,如果有信号则从队列中取数据,构建下发任务
将下发任务压入线程池工作任务队列,同时信号量递减1
SOAP报文保存线程,SOAP报文下发后会收到网元的响应报文,解析模块分析响应报文,获取SOAP发送报文的执行结果,并将执行失败
的SOAP报文进行保存,对执行成功的报文写入日志。
4. 连接池:连接池工厂,连接池,连接器实体
连接池工厂建立连接池名称和连接池实例的映射,管理所有连接池。
连接池管理所有会话连接(IOSession),建立空闲会话队列和使用会话队列,如果空闲队列为空,同时又有新的连接请求,则建立一条新的连接。
连接数不能超过最大连接数,如果已经达到最大连接数,则进入等待状态,当空闲队列空状态取消
AttachHttpHeader() // 附加Http报头
DetachHttpHeader() // 获取Http响应报头
PraseHttpHeader(); // 解析Http响应报头
队列采用状态模式,空闲状态
队列包含一个事件,类型转换操作符到事件句柄,当空闲队列为空时,事件变为无信号状态,当变为非空时变为有信号状态。每次出现这种状况都要写日志信息。
SpringBoot+CXF 实现简单的webservice,并支持Basic验证
CXF内置了很多拦截器,大部分默认添加到拦截器链中,有些拦截器也可以手动添加,如CXF的日志拦截器。如果需要自定义拦截器,只要继承AbstractPhaseInterceptor或者AbstractPhaseInterceptor的子类(如AbstractSoapInterceptor)
如果是传统的spring+cxf 项目,拦截器的写法是一样的,只是发布和配置的方法在cxf的配置文件的xml中进行
WSDL 地址:
CXF 自动编译解析的客户端
客户端basic 认证调用
cxf怎样提高webservice性能,及访问速度调优
1、 启用FastInfoset(快速信息集)
webservice的性能实在是不敢恭维。曾经因为webservice吞吐量上不
去,对webservice进行了一些性能方面的优化,采用了FastInfoset,效果很明显,极端条件下的大数据量传输,性能提高60%,他可以减
少传输成本,序列化成本和xml解析成本。
Cxf提供了FastInfoset协商机制,实现类见org.apache.cxf.feature.FastInfosetFeature,在bus中启用如下配置:
cxf:featurescxf:fastinfoset force="false"//cxf:features
Force=false表示服务端和客户端第一次通信时会协商(通过检查标准的HTTP头的Accept字段,值为MIME类型的application/fastinfoset)是否启用FastInfoset支持,如果客户端不支持,则不启用快速信息集。
需要在pom中添加依赖:
dependency
groupIdcom.sun.xml.fastinfoset/groupId
artifactIdFastInfoset/artifactId
version1.2.9/version
typejar/type
scopecompile/scope
/dependency
FastInfoset参考:
client和service端都要配置
2、 启用gzip压缩支持
客户端和服务器端是否使用Gzip压缩,也是基于http协议协商的(检查请求
header 中是否有Accept-encoding:gzip)。但是这里需要仔细权衡下。对于小数据量,启用gzip压缩支持是吃力不讨好的行为,
数据量很小的时候,gzip压缩结果不明显,还浪费cpu。我们需要权衡数据大小,按照经验设置threshold为10*1024byte。
在bus中启用如下配置:
bean class="org.apache.cxf.transport.common.gzip.GZIPFeature "
property name="threshold"value10240/value/property
/bean
官方文档指定是是配置org.apache.cxf.transport.http.gzip.GZIPFeature,但是这个类会找不到,可能是官方文档年久失修,造成一些混乱。官方文档中也没提示指定threshold,请参考GZIPFeature源代码。
参考
3、 使用slf4j代替cxf默认日志组件
CXF 默认使用java.util.logging作为日志打印组件,其性能我就不过多评价,也不太便于我们做统一日志管理。目前系统使用的slf4j作为日志打印组件,替换如下:
在classpath中加入META-INF/cxf/org.apache.cxf.Logger文件,文件内容为
org.apache.cxf.common.logging.Slf4jLogger
4、 测试中启用日志
bus中加入cxf:logging/,请在测试环境中启用有助于debug
补充:
1、如何自定义返回码:
请求在service中处理遇到异
常后,会调用请求链中所有拦截器的handleFault方法,参考PhaseInterceptorChain#unwind,然后判断请求是否单向请
求,如果不是,则构建异常请求链,并构建异常message对象,调用异常请求链中的handleMessage 方法(参
考:AbstractFaultChainInitiatorObserver)
JAXWSMethodInvoker
转发soap请求到指定对象的方法,如果在请求处理失败,调用updateHeader方法,把请求时的soap
header放入返回header中。但是不同通过继承JAXWSMethodInvoker来实现清除异常时soap
header也返回给客户端的问题,因为JAXWSMethodInvoker没有采用注入的机制
(JaxWsServerFactoryBean#createInvoker)也没有chain.异常时,会由这些拦截器处理返回请求:
setup [ServerPolicyOutFaultInterceptor]
prepare-send [MessageSenderInterceptor, Soap11FaultOutInterceptor]
pre-stream [LoggingOutInterceptor, StaxOutInterceptor]
pre-protocol [WebFaultOutInterceptor]
write [SoapOutInterceptor]
拦截器初始化类OutFaultChainInitiatorObserver
我们可以在异常链中加入清理soap header的拦截器SoapHeaderOutFilterInterceptor,清理掉在系统异常时soapheader中有信息的问题。
返回错误状态码,在执行Soap11FaultOutInterceptor拦截器中被写死。
message.put(org.apache.cxf.message.Message.RESPONSE_CODE, new Integer(500));
为了使返回数据中有错误码,需要在Soap11FaultOutInterceptor后面加入拦截器
2、在项目测试时遇到一个报错
invalid LOC header (bad
signature),这个问题是因为jar包损坏照成的,虽然构建路径中有这个jar,但是还是会出现loadClass失败,清理maven 本地仓
库目录的jar,修改pom(比如加上一空行)让m2e重新加载。
3、Cxf中有一个很不错的特性,支持javascript访问soap
webservice,客户端访问类似的请求,会生成
javascript 客户端,js编程时就可以使用此客户端提供的对象,启用此功能需要在引入
import resource="classpath:META-INF/cxf/cxf-extension-javascript-client.xml" /并且在依赖中加入:
dependency
groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-javascript/artifactId
version2.4.1/version
typejar/type
scopecompile/scope
/dependency