2018年10月22日工作总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/attack_breast/article/details/83302483

事情背景

客户端调用我方提供的web-service,由于我方的响应中带有Transfer-Encoding: chunked,这就意味着我方的响应是分段多次发送,而不是一次性全部发送,这就导致了客户端存在接收不全的问题:即可能无法接收全部响应,或者,接收响应的次序不对等问题。

事情经过

这个项目用的mule产品,公司里就我们部门在使用且本部门熟悉的人也不多,那也得做啊。事情大概分为几个阶段:

第一阶段:我熟悉MULE3.X产品的使用说明书,从里面查找类似的配置,你还别说找到了,只不过是配置在Apache CXF里面的,来设置客户端是否分段发送,但是不起作用。

第二阶段:后来领导提出一个建议那就是能不能在现有web-service的基础上,在它前面再搭建一个web-service,后来尝试了3种方案:①在mule前面搭建一个tomcat,但是这个项目是快上线的项目,这个时间成本太高。②基于mule自带的proxy来模拟web-service,这个问题是没有JAVA代码,所有资料只有JAVA类没有JAVA代码,放弃了。③更改Apache CXF的simple模式为jawxs模式,虽然改为jawxs模式后能获取到Response对象,但系统却无法正常工作,考虑到这是我第一次接触该项目,我心想坏了,没个半月是解决不了的。

第三阶段:我趁着周末仔仔细细看了HTTP的请求与响应,想从客户端入手。特别是HTTP 请求的TE参数让我燃起了希望,于是2018年10月22日我迫不及待的试了试,我擦,还是不行,心想完了完了。

第四阶段:我在Eclipse中编辑XML文件中,使用alt + ?时编辑器能提示XML节点的属性,我抱着试一试的态度查找可能有关的属性,你猜怎么着,成功了。

个人总结

①工作上的事情都需要一个结果。事情完成了则报告完成;事情没完成则报告为什么没有完成。

②基于上面的原则,接到事情后,应该新建WORD文档来详细记录事情的解决思路、从哪方面下手去解决,如果事情没解决的话,这份WORD最起码能证明你努力去解决事情了,只不过没有结果,最起码证明你的工作态度、工作方法。

③思路很重要,好的思路既能解决问题还能节省很多时间。

④没事多学习。

猜你喜欢

转载自blog.csdn.net/attack_breast/article/details/83302483