Oracle ebs（12）
最近一直在忙webservice 的工作，一共完成了两个外部系统调用EBS数据的项目，从中获得了一些经验和教训，随手写下来，以便以后的使用。
1、很少能出现一次调通的接口，在我工作的这两个项目中，有一个接口很简单，但是也出现了各种各样的问题。所以若希望问题少最好先在SOUP UI里调试，
由于开发人员、使用工具等等一系列的问题，webservice的头信息会有很大的区别，有时候一个符号不对就会无法验证通过，所以在SOUP UI里将错误的报文和
正确的报文进行仔细的对比，就能很好的解决很多问题。
2、oracle developer 工具的问题，在调试的过程中出现标签缺失的情况，由于一个属性为空值，导致整个标签的后半部分都缺失了,例如&a&1&/a&&b&2&/b&由于a属性为空
导致标签变成了&a&2&b&&&& 所以尽量避免传空值，在传递之前做好所有的验证工作。如标签缺失会出现以下错误，之前以为是库中有乱码，找了好半天。
信息Unmarshalling Error: Illegal character (NULL, unicode 0) encountered: not valid in any content
&at [row,col {unknown-source}]: [1,696]
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：5996次
排名：千里之外
原创：13篇
(3)(2)(2)(8)14:06 提问
soapui调用webservice接口，已传入参数，但是无返回值，只有一堆标签，求解答，谢谢~~~
soapui调用webservice接口，已传入参数，但是无返回值，只有一堆标签，求解答，谢谢~~~
按赞数排序
我也遇到这种问题，不知道是什么原因
我也遇到了。没人解答呢。。
106关注|648收录
7732关注|1460收录
405关注|183收录
其他相似问题用webservice发布应用，如果某一时间并发量很大，无法全部进行处理，如何处理使其不丢失数据？
该问题被发起重新开启投票
投票剩余时间：
之前被关闭原因：
该问题被发起删除投票
投票剩余时间：
距离悬赏到期还有：
参与关闭投票者：
关闭原因：
该问题已经被锁定
锁定原因：（）
保护原因：避免来自新用户不合宜或无意义的致谢、跟帖答案。
该问题已成功删除，仅对您可见，其他人不能够查看。
比较简单的方法就是使用队列缓存，然后从队列当中取数据进行处理。HttpSQS源码好像是用c写的，总代码据说才800多行，但没怎么用过，支持的并发不太清楚；再就是MQ较常用，并发貌似能达到10000+，应该就够用了。
可以从三个方向做，1是减少客户端无用的请求建立数据缓存，增量更新等机制尽量减少客户端的请求。
2.提前准备数据，减少实时的数据处理。对一些请求较频繁的接口，提前处理好数据，减少cpu实时运算
3.缓存数据到redis或者memcached中，减少硬盘读写时间，提高响应速度。
用可持久化队列呗，httpsqs就挺好的，memcached也OK。
用队列分批进行请求和处理，并对每个记录的状态进行记录，这样就可以知道哪些数据丢失了，把丢失的数据再重新请求或处理直到成功为止，这样就可以避免丢失数据了！
所有的请求都放入一个pool里去，至于这个pool这么实现，有很多方法cache等都可以，然后建立高低水位线，去从这些pool里去取数据来处理就可以了
一、不花钱的 代理HAProxy/Nginx 后面挂N个WebServer 也可以保证Session问题。至于你说的大批量并发有多少。二、同步处理异步处理同步处理，请求-》业务逻辑-》应答
有个耗时异步处理，请求-》存储-》应答
耗时比业务逻辑要少很多。存储可用FQueue 内存映射+文件。异步就是多一个请求。要结果。所以请求的时候加一个messageid唯一值由另外的接口返回。
用队列就可以解决问题,或者使用worker模式进行处理,client阻塞住等待处理完成获得回调值如果请求堆积不会很多,处理不是太慢没必要持久化
不是您所需，查看更多相关问题与答案
德问是一个专业的编程问答社区，请
后再提交答案
关注该问题的人
共被浏览 (14399) 次webservice axis2 的问题，我在客户端stub端并发每15秒100条的量，请求两个小时时间，就会出现超时错误。_百度知道
webservice axis2 的问题，我在客户端stub端并发每15秒100条的量，请求两个小时时间，就会出现超时错误。
　可能是服务端处理能力不足，就会出现超时错误。　　解决办法就是一是客户端的请求数减小或增加请求间隔，就是服务器端15秒不能处理100条的量，如果超时时间延长就可能是服务端处理能力不足。　　你可以把客户端的请求数减小或增加请求间隔试试看，增加处理能力，剩余的会一直积压，二是更改服务器端程序和配置，最后有的信息不能再超时前得到处理
谢谢你的回答，他是每条请求都有返回值的，2个小时内都正常，但是就整点2个小时就会超时，我现在减少并发量测试测试，看看结果。
哦，你可以看看这个：可能会有帮助。
其他类似问题
为您推荐：
axis2的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁编程实践笔记{Java 线程 并发处理 Webservice} - 两颗番茄 - 博客园
1, 保证线程安全的三种方法:
&&& a, 不要跨线程访问共享变量
&&& b, 使共享变量是final类型的
&&& c, 将共享变量的操作加上同步
2, 一开始就将类设计成线程安全的, 比在后期重新修复它,更容易.
3, 编写多线程程序, 首先保证它是正确的, 其次再考虑性能.
4, 无状态或只读对象永远是线程安全的.
5, 不要将一个共享变量裸露在多线程环境下(无同步或不可变性保护)
6, 多线程环境下的延迟加载需要同步的保护, 因为延迟加载会造成对象重复实例化
7, 对于volatile声明的数值类型变量进行运算, 往往是不安全的(volatile只能保证可见性,不能保证原子性).
详见volatile原理与技巧中, 脏数据问题讨论.
8, 当一个线程请求获得它自己占有的锁时(同一把锁的嵌套使用), 我们称该锁为可重入锁.
在jdk1.5并发包中, 提供了可重入锁的java实现-ReentrantLock.
9, 每个共享变量,都应该由一个唯一确定的锁保护.
创建与变量相同数目的ReentrantLock, 使他们负责每个变量的线程安全.
10,虽然缩小同步块的范围, 可以提升系统性能.
但在保证原子性的情况下, 不可将原子操作分解成多个synchronized块.
11, 在没有同步的情况下, 编译器与处理器运行时的指令执行顺序可能完全出乎意料.
原因是, 编译器或处理器为了优化自身执行效率, 而对指令进行了的重排序(reordering).
12, 当一个线程在没有同步的情况下读取变量, 它可能会得到一个过期值, 但是至少它可以看到那个
线程在当时设定的一个真实数值. 而不是凭空而来的值. 这种安全保证, 称之为最低限的安全性(out-of-thin-air safety)
在开发并发应用程序时, 有时为了大幅度提高系统的吞吐量与性能, 会采用这种无保障的做法.
但是针对, 数值的运算, 仍旧是被否决的.
13, volatile变量,只能保证可见性, 无法保证原子性.
详见 原理与技巧
15, 发布(publish)对象, 指的是使它能够被当前范围之外的代码所使用.(引用传递)
对象逸出(escape), 指的是一个对象在尚未准备好时将它发布.原则: 为防止逸出, 对象必须要被完全构造完后, 才可以被发布(最好的解决方式是采用同步)
this关键字引用对象逸出
例子: 在构造函数中, 开启线程, 并将自身对象this传入线程, 造成引用传递.
而此时, 构造函数尚未执行完, 就会发生对象逸出了.
良好的多线程编程习惯是: 将所有的域都声明为final, 除非它们是可变的18, 保证共享变量的发布是安全的
&&& a, 通过静态初始化器初始化对象(jls 12.4.2叙述, jvm会保证静态初始化变量是同步的)
&&& b, 将对象申明为volatile或使用AtomicReference
&&& c, 保证对象是不可变的
&&& d, 将引用或可变操作都由锁来保护20, 将数据封装在对象内部, 并保证对数据的访问是原子的.
建议采用volatile javabean模型或者构造同步的getter,setter.
22, 编写并发程序, 需要更全的注释, 更完整的文档说明.24, 设计并发程序时, 在保证伸缩性与性能折中的前提下, 优先考虑将共享变量委托给线程安全的类.
由它来控制全局的并发访问.
25, 使用普通同步容器(Vector, Hashtable)的迭代器, 需要外部锁来保证其原子性.
原因是, 普通同步容器产生的迭代器是非线程安全的.
26, 在并发编程中, 需要容器支持的时候, 优先考虑使用jdk并发容器
(ConcurrentHashMap, ConcurrentLinkedQueue, CopyOnWriteArrayList...).
27, ConcurrentHashMap, CopyOnWriteArrayList并发容器的迭代器,以及全范围的size(), isEmpty() 都表现出弱一致性.
他们只能标示容器当时的一个数据状态. 无法完整响应容器之后的变化和修改.
28, 使用有界队列, 在队列充满或为空时, 阻塞所有的读与写操作. (实现生产-消费的良好方案)
BlockQueue下的实现有LinkedBlockingQueue与ArrayBlockingQueue, 前者为链表, 可变操作频繁优先考虑,后者为数组, 读取操作频繁优先考虑.
PriorityBlockingQueue是一个按优先级顺序排列的阻塞队列, 它可以对所有置入的元素进行排序(实现Comparator接口)
29, 当一个方法, 能抛出InterruptedException, 则意味着, 这个方法是一个可阻塞的方法, 如果它被中断, 将提前结束阻塞状态.
当你调用一个阻塞方法, 也就意味着, 本身也称为了一个阻塞方法, 因为你必须等待阻塞方法返回.
如果阻塞方法抛出了中断异常, 我们需要做的是, 将其往上层抛, 除非当前已经是需要捕获异常的层次.
如果当前方法, 不能抛出InterruptedException, 可以使用Thread.currentThread.interrupt()方法, 手动进行中断.
===================================================
Webservices :找到项目工程中*.wsdl文件--》Webservices 》Test with webservices exploer
阅读(...) 评论()
Powered By:}