No exception. It just stays stuck on the httpclient.execute() line. I'll gather 
the wire logs.




---- On Fri, 29 Mar 2019 08:44:02 -0700 Oleg Kalnichevski 
<[email protected]> wrote ----



On Fri, 2019-03-29 at 08:37 -0700, Mark Cafaro wrote: 

> I mean to say when I'm using the Apache client, I see the server 

> sends back a proper response but the client never receives it (it 

> just stays stuck on httpclient.execute()). So, on the server side, 

> irrespective of the execution path it is taking, I  ultimately know 

> it is sending back a response. Why the client is not reacting to that 

> response is the head scratcher. 

> 

 

What means "not reacting to that response"? This makes no sense. Does 

it throw an exception of any sort? 

 

Oleg 

 

> 

> 

> -Mark 

> 

> 

> 

> 

> ---- On Fri, 29 Mar 2019 08:12:34 -0700 Oleg Kalnichevski < 

> mailto:[email protected]> wrote ---- 

> 

> 

> 

> On Fri, 2019-03-29 at 08:09 -0700, Mark Cafaro wrote: 

> 

> > What makes me think it's a client side issue is that I can take 

> > the 

> > same request and run it with cURL and properly receive a response. 

> > I 

> > can also view the logs on the server side and see that a response 

> > was 

> > sent back. 

> > 

> > 

> 

> 

> 

> So what? That means absolutely nothing. Clients can behave 

> differently 

> 

> enough to trigger a different execution path on the server side. 

> 

> 

> 

> Oleg 

> 

> 

> 

> > 

> > I'll try turning on wire logging and see if that gives me any 

> > clues. 

> > Thanks. 

> > 

> > 

> > 

> > 

> > ---- On Fri, 29 Mar 2019 06:38:45 -0700 Oleg Kalnichevski < 

> > mailto:mailto:[email protected]> wrote ---- 

> > 

> > 

> > 

> > On Fri, 2019-03-29 at 06:34 -0700, Mark Cafaro wrote: 

> > 

> > > The call to httpclient.execute() is just stuck until the 

> > > eventual 

> > > socket timeout is reached. 

> > > 

> > > 

> > 

> > 

> > 

> > What makes you think this is a client side issue? Have you tried 

> > 

> > running your application with HttpClient wire logging turned out 

> > and 

> > 

> > analyzing data packets sent on the wire? 

> > 

> > 

> > 

> > Oleg 

> > 

> > 

> > 

> > 

> > 

> > > 

> > > -Mark 

> > > 

> > > 

> > > 

> > > P.S. Sorry if this created a new thread. I did not subscribe in 

> > > time 

> > > to get the first reply. 

> > > 

> > > 

> > > > What exactly do you mean by "never receives a response"? What 

> > > > happens 

> > > > instead? 

> > > > 

> > > > Oleg 

> > > > 

> > > > > Hi, 

> > > > > 

> > > > > I am running long HTTP post requests on Travis CI (Ubuntu 

> > > > > 14.04) 

> > > > > using the Apache HTTP Client. Strangely if a request exceeds 

> > > > > about 8 

> > > > > minutes, the client never receives a response. I can see on 

> > > > > the 

> > > > > server side, however, that a response was sent back. I have 

> > > > > the 

> > > > > socket timeout set way beyond 8 minutes. 

> > > > > 

> > > > > If I perform the exact same request, on the exact same 

> > > > > machine, 

> > > > > using 

> > > > > cURL however, it works as expected (i.e. cURL receives a 

> > > > > response). 

> > > > > Also, if I perform the exact same request using the Apache 

> > > > > HTTP 

> > > > > Client on my local machine, it works as expected. 

> > > > > 

> > > > > I've tried playing around with sysctl 

> > > > > net.ipv4.tcp_keepalive_time, tcp_keepalive_intvl, 

> > > > > and tcp_keepalive_probes but they haven't solved the issue. 

> > > > > 

> > > > > Are there any settings in the Apache HTTP Client that may be 

> > > > > relevant 

> > > > > to this issue? 

> > > > > 

> > > > > Thanks, 

> > > > > 

> > > > > Mark 

> > 

> > 

> > 

> > 

> > 

> > ----------------------------------------------------------------- 

> > -- 

> > -- 

> > 

> > To unsubscribe, e-mail: mailto: 

> > mailto:mailto:[email protected] 

> > 

> > For additional commands, e-mail: mailto: 

> > mailto:mailto:[email protected] 

> 

> 

> 

> 

> 

> ------------------------------------------------------------------- 

> -- 

> 

> To unsubscribe, e-mail: mailto: 

> mailto:[email protected] 

> 

> For additional commands, e-mail: mailto: 

> mailto:[email protected] 

 

 

--------------------------------------------------------------------- 

To unsubscribe, e-mail: mailto:[email protected] 

For additional commands, e-mail: mailto:[email protected]

Reply via email to