scala - Cómo corregir el cierre de caída ya que la conexión SSL ya está cerrando el error en la pulverización

akka spray

Question

Estoy haciendo una llamada a una API, pero la mayoría de las veces recibo un error: " Descartar cierre porque la conexión SSL ya se está cerrando " y " Cierre prematuro de conexión (el servidor no parece admitir la canalización de solicitudes) . ”Como el 90% de las veces, recibo ese error, lo que significa que, en muy raras ocasiones, la consulta devuelve los datos que supone.

Para asegurarme de que este no era el problema del servidor de la API, replico la misma consulta usando Node.js (Express y Request libs) y funciona siempre. Me hace casi seguro que es un error de spray .

Aquí hay un ejemplo del código :

case class MyClass(user: String, pass: String)
class MyActor extends Actor {
import spray.client.pipelining._
import spray.http.BasicHttpCredentials
import spray.http.{HttpRequest,HttpResponse}
import scala.concurrent.Future
import context.dispatcher
def receive = {
case myClass: MyClass => {
val credentials: BasicHttpCredentials = BasicHttpCredentials(myClass.user, myClass.pass)
val url: String = "https://myApi?params=values"
val request: HttpRequest = Get(url) ~> addCredentials(credentials)
val pipeline = sendReceive
val response: Future[HttpResponse] = pipeline(request)
val finalRes: Future[String] = response.map{ r =>
println(r)
r.entity.asString
}
finalRes pipeTo sender
}
} // end receive
} //end Actor

Detalle de error :

04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-8] a.i.TcpOutgoingConnection - Attempting connection to ...
04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-6] a.i.TcpOutgoingConnection - Connection established to ...
04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-6] s.c.c.HttpClientConnection - Connected to ...
04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-9] s.c.c.HttpHostConnectionSlot - Connection to ... established, dispatching 1 pending requests
04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-3] s.c.c.HttpClientConnection - now monitoring Actor[akka://on-spray-can/system/IO-TCP/selectors/$a/5]
04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-6] s.c.c.HttpHostConnectionSlot - Dispatching GET request to /api?params=values across connection Actor[akka://on-spray-can/user/IO-HTTP/group-0/4]
04/01 10:19:05 DEBUG[on-spray-can-akka.actor.default-dispatcher-6] s.c.c.HttpHostConnectionSlot - now monitoring Actor[akka://on-spray-can/user/IO-HTTP/group-0/4]
04/01 10:19:06 DEBUG[on-spray-can-akka.actor.default-dispatcher-3] s.c.c.HttpClientConnection - Dropping Close since the SSL connection is already closing
04/01 10:19:06 DEBUG[on-spray-can-akka.actor.default-dispatcher-3] s.c.c.HttpClientConnection - Connection was PeerClosed, awaiting TcpConnection termination...
04/01 10:19:06 DEBUG[on-spray-can-akka.actor.default-dispatcher-3] a.i.TcpOutgoingConnection - stopped
04/01 10:19:06 DEBUG[on-spray-can-akka.actor.default-dispatcher-3] s.c.c.HttpClientConnection - TcpConnection terminated, stopping
04/01 10:19:06 WARN [on-spray-can-akka.actor.default-dispatcher-3] s.c.c.HttpHostConnectionSlot - Premature connection close (the server doesn''t appear to support request pipelining) in response to GET request to /myApi?params=values with 1 retries left, retrying...
04/01 10:19:06 DEBUG[on-spray-can-akka.actor.default-dispatcher-3] s.c.c.HttpClientConnection - stopped

Y pude reproducir el error en todas estas versiones :

spray 1.0.1; akka 2.0.5; scala 2.9.3
spray 1.2.1; akka 2.2.4; scala 2.10.1
spray 1.3.1; akka 2.3.0; scala 2.10.3
spray 1.3.2; akka 2.3.6; scala 2.11.4
spray 1.3.3; akka 2.3.9; scala 2.11.6

Answer 1

como dijiste,

Para asegurarme de que este no era el problema del servidor de la API, replico la misma consulta usando Node.js (Express y Request libs) y funciona siempre. Me hace casi seguro que es un error de spray.

su código en scala envía solicitudes con la función de canalización de HTTP, ¿envía las solicitudes con la función de canalización de HTTP mientras prueba con nodejs?

mensaje de error:

el servidor no parece admitir la canalización de solicitudes

usted debe asegurarse

1. asegúrese de que el servidor admita la función de canalización y que la función de canalización esté habilitada.
2. Si hay servidores proxy entre su cliente y el servidor (incluya proxy inverso), asegúrese de que los servidores proxy admitan la función de canalización y que la función de canalización esté habilitada.

Si no puede asegurarse de que la función de canalización se admita correctamente, no debe usarla.

siguiente recurso puede ser útil:

La canalización HTTP requiere que tanto el cliente como el servidor lo admitan. Los servidores que cumplen con HTTP / 1.1 son necesarios para admitir la canalización. Esto no significa que los servidores deban canalizar las respuestas, sino que se requiere que no fallen si un cliente elige canalizar las solicitudes. [7]

https://en.wikipedia.org/wiki/HTTP_pipelining

La canalización HTTP no está activada por defecto en los navegadores modernos:

Los proxies con errores aún son comunes y conducen a comportamientos extraños y erráticos que los desarrolladores web no pueden prever y diagnosticar fácilmente. La implementación de la canalización es compleja: el tamaño del recurso que se transfiere, el RTT efectivo que se utilizará, así como el ancho de banda efectivo, tienen una incidencia directa en la mejora proporcionada por el oleoducto. Sin saber esto, los mensajes importantes pueden retrasarse detrás de los que no son importantes. ¡La noción de importante incluso evoluciona durante el diseño de la página! Por lo tanto, la canalización HTTP trae una mejora marginal en la mayoría de los casos solamente. La canalización está sujeta al problema HOL. Por estas razones, la canalización ha sido sustituida por un algoritmo mejor, el multiplexado, que utiliza HTTP / 2.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x $ revision / 1330814