【问题标题】:Streaming via SOAP?通过 SOAP 流式传输?
【发布时间】:2012-07-19 20:26:43
【问题描述】:

我有 WS,其中 SOAP 有效负载中有一个 xsd:base64Binary 元素。

最初这是为最大 1MB 设计的,但要求发生了变化,现在它应该接受转换为 base64 的 50 MB 上传文件:(在 java 中,这在内存方面变得巨大。

我的理论解决方案是将这些“附件”从一端流到另一端 (文件从 Web 应用程序上传,然后转换为 base64 并调用 Web 服务以存储在某些 Adob​​e 应用程序中) - 我说效率非常低

我阅读了有关 Stax 的信息,但那不是针对 WebServices 的。

有没有办法将流与 Web 服务结合使用?

(MTOM,但没有找到带流式传输的示例)

【问题讨论】:

标签: java performance web-services streaming java-metro-framework


【解决方案1】:

我认为您可以使用自定义 servlet 并覆盖 post 方法来做到这一点。

通过 Stax 读取足够多的请求 InputStream 以找到包含 base64 的元素,然后将其通过管道传输到某种 Base64InputStream 直到到达元素的末尾。使用 Stax 或 JaxB 将对象转换为响应并将其发送回。

无论您做什么,都不要缓冲整个请求。不要在不考虑它如何处理缓冲的情况下使用典型的肥皂框架,如 CXF 或 JAXWS。你会对你的垃圾收集器造成如此沉重的打击,它会惊慌失措,逃跑,再也不会给你打电话了。

编辑:垃圾收集

如果您运行的是 4gb 堆,并且假设您使用的是 HotSpot,请确保您使用的是 Oracle 的最新 Java (7u5)。接下来,切换到用于处理大型堆的收集器:g1gc (-XX:+UseG1GC) 或 CMS (-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode)

此外,请考虑添加以下内容:

-XX:+OptimizeStringConcat -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:+UseLargePages -XX:+UseStringCache -XX:+UseCompressedOops

【讨论】:

  • 确实...服务器现在有 4gb...但是 gc 需要超过 1 分钟。无论如何...当 gc 运行时为什么整个 JVM 冻结?
  • JVM 中的用户线程被冻结,因为您使用的垃圾收集器是“停止世界”的设计。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-06-20
  • 1970-01-01
  • 2013-04-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-03-30
相关资源
最近更新 更多