Playframework 在play2.4.6中发送多部分表单数据时超时

Playframework 在play2.4.6中发送多部分表单数据时超时,playframework,multipartform-data,playframework-2.4,Playframework,Multipartform Data,Playframework 2.4,我试图转到2.4.6版,但我正在努力更新我的多部分/表单数据发布。使用的“旧”代码: import com.ning.http.multipart._ libs 而且非常直截了当: val parts = Array[Part]( new FilePart("file", currentFile) ) val mpre = new MultipartRequestEntity(parts, new FluentCaseInsensitiveStringsMap) val baos =

我试图转到2.4.6版,但我正在努力更新我的多部分/表单数据发布。使用的“旧”代码:

import com.ning.http.multipart._ libs
而且非常直截了当:

val parts = Array[Part](
   new FilePart("file", currentFile)
)

val mpre = new MultipartRequestEntity(parts, new FluentCaseInsensitiveStringsMap)
val baos = new ByteArrayOutputStream
mpre.writeRequest(baos)
val bytes = baos.toByteArray
val contentType = mpre.getContentType     
// Now just send the data to the WS API
 WS.url(url)
    .post(bytes)(Writeable.wBytes, ContentTypeOf(Some(contentType))).map { response =>
    Logger.info("" + response.status)
//  Cool code here to handle stuff
}
现在看来,MultipartRequestEntity和所有这些好东西都消失了。。所以我试着这样重写它(为难看的黑客代码感到抱歉:):

但是这里发生的是,请求在默认秒数之后超时。 当然,我已经尝试使用api,这很有魅力:

curl --form file=@Path/to/file/file.pdf 'https://url'    
我可能错过了一些非常琐碎的事情,但是什么呢

堆栈跟踪超时

    [debug] - play.api.libs.ws.ning.NingAsyncHttpClientConfigBuilder - buildHostnameVerifier: enabling hostname verification using class play.api.libs.ws.ssl.DefaultHostnameVerifier
[debug] - org.jboss.netty.channel.DefaultChannelFuture - The dead lock checker in DefaultChannelFuture has been disabled as requested at your own risk.
[info] - application - parts[FilePart name=deevi-sthlm_1424182188313.pdf contentType=application/octet-stream charset=null tranferEncoding=binary contentId=null dispositionType=null filename=deevi-sthlm_1424182188313.pdf]
[debug] - org.jboss.netty.handler.ssl.SslHandler - [id: 0xe4b02f13, /192.168.1.197:50403 => cool.api.com/212.16.165.50:443] HANDSHAKEN: TLS_RSA_WITH_AES_128_CBC_SHA
[debug] - com.ning.http.client.providers.netty.request.NettyConnectListener - Request using non cached Channel '[id: 0xe4b02f13, /192.168.1.197:50403 => cool.api.com/212.16.165.50:443]':
DefaultHttpRequest(chunked: false)
POST /api/v2/7519/resources/upload/internal/order/23/?token=aaaaaaaa HTTP/1.1
Content-Length: 919937
Content-Type: multipart/form-data; boundary=pKuhU4cHh8J6RhA1tqOEeujTjvje06TC8AW8ZvZD
Connection: keep-alive
Host: cool.api.com
Accept: */*
User-Agent: AHC/1.0

[debug] - com.ning.http.client.providers.netty.channel.pool.DefaultChannelPool - Closed 0 connections out of 0 in 0ms
[debug] - com.ning.http.client.providers.netty.channel.pool.DefaultChannelPool - Closed 0 connections out of 0 in 0ms
[debug] - com.ning.http.client.providers.netty.request.timeout.TimeoutTimerTask - Request timed out to cool.api.com/212.16.165.50:443 of 120000 ms for NettyResponseFuture{currentRetry=0,
    isDone=false,
    isCancelled=false,
    asyncHandler=com.ning.http.client.AsyncCompletionHandlerBase@293e6e7c,
    nettyRequest=com.ning.http.client.providers.netty.request.NettyRequest@5b564b51,
    content=null,
    uri=https://cool.api.com/api/v2/7519/resources/upload/internal/order/23/?token=aaaaa,
    keepAlive=true,
    httpHeaders=null,
    exEx=null,
    redirectCount=0,
    timeoutsHolder=com.ning.http.client.providers.netty.request.timeout.TimeoutsHolder@51f45b89,
    inAuth=false,
    statusReceived=false,
    touch=845942276} after 120333 ms
[debug] - com.ning.http.client.providers.netty.channel.ChannelManager - Closing Channel [id: 0xe4b02f13, /192.168.1.197:50403 => cool.api.com/212.16.165.50:443] 
[debug] - com.ning.http.client.providers.netty.request.NettyRequestSender - Aborting Future NettyResponseFuture{currentRetry=0,
    isDone=false,
    isCancelled=false,
    asyncHandler=com.ning.http.client.AsyncCompletionHandlerBase@293e6e7c,
    nettyRequest=com.ning.http.client.providers.netty.request.NettyRequest@5b564b51,
    content=null,
    uri=https://cool.api.com/api/v2/7519/resources/upload/internal/order/23/?token=214141414,
    keepAlive=true,
    httpHeaders=null,
    exEx=null,
    redirectCount=0,
    timeoutsHolder=com.ning.http.client.providers.netty.request.timeout.TimeoutsHolder@51f45b89,
    inAuth=false,
    statusReceived=false,
    touch=845942276}

[debug] - com.ning.http.client.providers.netty.handler.Processor - Channel Closed: [id: 0xe4b02f13, /192.168.1.197:50403 :> cool.api.com/212.16.165.50:443] with attribute INSTANCE
[debug] - com.ning.http.client.providers.netty.request.NettyRequestSender - Request timed out to cool.api.com/212.16.165.50:443 of 120000 ms
java.util.concurrent.TimeoutException: Request timed out to cool.api.com/212.16.165.50:443 of 120000 ms
    at com.ning.http.client.providers.netty.request.timeout.TimeoutTimerTask.expire(TimeoutTimerTask.java:47) [async-http-client-1.9.21.jar:na]
    at com.ning.http.client.providers.netty.request.timeout.RequestTimeoutTimerTask.run(RequestTimeoutTimerTask.java:48) [async-http-client-1.9.21.jar:na]
    at org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:556) [netty-3.10.4.Final.jar:na]
    at org.jboss.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:632) [netty-3.10.4.Final.jar:na]
    at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:369) [netty-3.10.4.Final.jar:na]
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.4.Final.jar:na]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
[debug] - com.ning.http.client.AsyncCompletionHandlerBase - Request timed out to cool.api.com/212.16.165.50:443 of 120000 ms
java.util.concurrent.TimeoutException: Request timed out to cool.api.com/212.16.165.50:443 of 120000 ms
    at com.ning.http.client.providers.netty.request.timeout.TimeoutTimerTask.expire(TimeoutTimerTask.java:47) [async-http-client-1.9.21.jar:na]
    at com.ning.http.client.providers.netty.request.timeout.RequestTimeoutTimerTask.run(RequestTimeoutTimerTask.java:48) [async-http-client-1.9.21.jar:na]
    at org.jboss.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:556) [netty-3.10.4.Final.jar:na]
    at org.jboss.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:632) [netty-3.10.4.Final.jar:na]
    at org.jboss.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:369) [netty-3.10.4.Final.jar:na]
    at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.4.Final.jar:na]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]

我还尝试发布以下内容:

.addHeader("Expect", "100-continue")
.addHeader("Content-Type","application/x-www-form-urlencoded")
但是得到的413请求实体太大

Request DefaultHttpRequest(chunked: false)
POST /api/v2/7519/resources/upload/internal/order/23/?token=aaaaaaa HTTP/1.1
Expect: 100-continue
Content-Length: 919931
Content-Type: application/x-www-form-urlencoded; boundary=pI11GyXoLyybJYI3pR9iMZDgu8D1ZaH_Y4Qmc
Connection: keep-alive
Host: power.upsales.com
Accept: */*
User-Agent: AHC/1.0

Response DefaultHttpResponse(chunked: false)
HTTP/1.1 413 Request Entity Too Large
Server: nginx/1.4.4
Date: Thu, 11 Feb 2016 08:12:50 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 1206
Connection: keep-alive
X-Content-Type-Options: nosniff
您可能遇到了4个月前修复并在AsyncHttpClient 1.9.32中发布的问题

默认情况下:(

升级。

您可能遇到了4个月前修复并在AsyncHttpClient 1.9.32中发布的问题

默认情况下:(


升级。

Stephane您之前的答案(您删除的答案:))让我想,也许服务器在期待什么,但我错过了。于是我跳进了 curl请求和scala请求代码和解决方案都很简单。添加filepart时,第一个参数应为“file”,否则服务器将不会处理该文件

.addBodyPart(new FilePart("file", new File("/Path/to/file/file.pdf")))
代码如下所示。我还实现了一个异步版本,使其更像Play2:

def uploadFileForOrder(id: Long) = Action.async {
implicit request =>

    import com.ning.http.client._
    import com.ning.http.client.{Response => AHCResponse}
    import com.ning.http.client.AsyncHttpClient
    import com.ning.http.client.AsyncCompletionHandler
    import com.ning.http.client.multipart.FilePart
    import com.ning.http.client.multipart.StringPart
    import java.io.File
    import play.api.libs.ws._
    import play.api.libs.ws.ning.NingWSResponse
    import scala.concurrent.{Future, Promise}


    val asyncHttpClient: AsyncHttpClient = WS.client.underlying
    val postBuilder =
      asyncHttpClient.preparePost("https://cool.api.com/api/resources/upload/internal/order/23/?token=asdasdasdasda")
      val builder = postBuilder
      .addBodyPart(new FilePart("file", new File("/Path/to/file/file.pdf")))
      .addHeader("Expect", "100-continue")

      val request = builder.build()
      val result = Promise[NingWSResponse]()
      asyncHttpClient.executeRequest(request, new AsyncCompletionHandler[AHCResponse]() {
        override def onCompleted(response: AHCResponse) = {
          result.success(play.api.libs.ws.ning.NingWSResponse(response))
          response
        }
        override def onThrowable(t: Throwable) {
          result.failure(t)
        }
      })
      val postFuture = result.future
      postFuture.map { response =>
        Ok("status"+response.statusText)
      }.recover {
        case e: Throwable => {
          BadRequest("error" + e)
        }
      }
    }

Stephane你之前的回答(你删除的那一个:))让我想,也许服务器在期待什么,但我错过了。于是我跳进了 curl请求和scala请求代码和解决方案都很简单。添加filepart时,第一个参数应为“file”,否则服务器将不会处理该文件

.addBodyPart(new FilePart("file", new File("/Path/to/file/file.pdf")))
代码如下所示。我还实现了一个异步版本,使其更像Play2:

def uploadFileForOrder(id: Long) = Action.async {
implicit request =>

    import com.ning.http.client._
    import com.ning.http.client.{Response => AHCResponse}
    import com.ning.http.client.AsyncHttpClient
    import com.ning.http.client.AsyncCompletionHandler
    import com.ning.http.client.multipart.FilePart
    import com.ning.http.client.multipart.StringPart
    import java.io.File
    import play.api.libs.ws._
    import play.api.libs.ws.ning.NingWSResponse
    import scala.concurrent.{Future, Promise}


    val asyncHttpClient: AsyncHttpClient = WS.client.underlying
    val postBuilder =
      asyncHttpClient.preparePost("https://cool.api.com/api/resources/upload/internal/order/23/?token=asdasdasdasda")
      val builder = postBuilder
      .addBodyPart(new FilePart("file", new File("/Path/to/file/file.pdf")))
      .addHeader("Expect", "100-continue")

      val request = builder.build()
      val result = Promise[NingWSResponse]()
      asyncHttpClient.executeRequest(request, new AsyncCompletionHandler[AHCResponse]() {
        override def onCompleted(response: AHCResponse) = {
          result.success(play.api.libs.ws.ning.NingWSResponse(response))
          response
        }
        override def onThrowable(t: Throwable) {
          result.failure(t)
        }
      })
      val postFuture = result.future
      postFuture.map { response =>
        Ok("status"+response.statusText)
      }.recover {
        case e: Throwable => {
          BadRequest("error" + e)
        }
      }
    }

超时发生在哪里?是否是
操作
?AsyncHttpClient发出的请求?在另一个地方?您可以将日志级别设置为debug以便我们可以在这里获得更多信息吗?超时发生在哪里?是否是
操作
?AsyncHttpClient发出的请求?在另一个地方?能否将日志级别设置为debug,以便我们可以在此处获得更多信息?请参阅下面的答案。不需要升级,但你之前的回答让我看到了正确的方向。谢谢你!见下面我的答案。不需要升级,但你之前的回答让我看到了正确的方向。谢谢你!