OW2 Forge: Detail: 304310 Problems with (Jetti based) HTTP Transport activation/deactivation

Advanced - Powered by Google

Log In
New Account
My Page
Project Tree
Project Openings
Celtix ESB

Tracker: Bugs

Submit New | Browse | Admin | ExportToXml

[ #304310 ] Problems with (Jetti based) HTTP Transport activation/deactivation

2005-11-22 18:31
Submitted By:
Andrea Smyth (andrea)
Assigned To:
Daniel Kulp (dkulp)
Problems with (Jetti based) HTTP Transport activation/deactivation

Detailed description:
If, after creating a server and client http transport, the following sequence: 1 send/receive request 2 deactivate server 3 send/receive request and expect exception becuase server has been deactivated 4 re-activate server 5 expect next send/reseive request to pass is executed repeatedly, it fails on the second time in step 4 unless the following step is executed also: 6 deactivate server In that siutation now repeated execution of the above sequence passes fine on some machines (e.g. a one processor Windows machine) but fails on others (e.g. a Solaris with 2 CPUs) when executing step 1 for the second time. This is regardless of whether the requests are handled on threads supplied by an executor or by the transport's own threads and can be reproduced by running test case HTTPTransportTest after a) commenting line 55 in or b) renaming test xtestHTTPTransportUsingAutomaticWorkQueue to testHTTPTransportUsingAutomaticWorkQueue The fact that step 2 is executed twice (for requests of small and large size resp.) is not relevant in this context.

Add A Comment:

Please login


Date: 2005-12-09 00:51
Sender: dkulp
Logged In: YES 

This seems to be a bug in the jetty stuff.  I sent a note  
to the jetty folks:  
 Today 06:24:59 pm 
I think I've found a bug in Jetty that is causing me a 
bunch of problems  
in my application.  Basically, in our application we may 
need to create  
semi-short lived HttpServers listening on a particular 
port.  They  
process for a while and then may be completely shutdown.   
Later, we may  
need to bring up a new one to process something else, 
etc...   When we  
stop the server, we'd like to just let the garbage 
collector clean it up  
as we don't know if it will be needed again. 
There seems to be a problem with HttpServer.stop(true) in 
that it's  
leaving some sort of state around.   When we startup a 
second one later,  
it dispatches to the right handler, but trying to read 
data from the  
stream just blocks until timeout.  I have no idea what is 
going on.    
I've attached a sample that shows the problem.  (Linux, 
jdk 1.5.0_06)   
When run, I get: 
Dispatching: /Test 
Read: 5000 
SocketListener0-1: Echoed: 5000 
Dispatching: /Test 
Read: 5000 
SocketListener0-1: Echoed: 5000 
Dispatching: /Test Read timed out 
If I add a "connection.disconnect();" line to the end
runClient(), it  
works fine, but we'd obviously like to not have to do that 
performance reasons.  Besides, we don't have control over 
all the client  
code.  It seems like even after server.stop(), SOMETHING  
is sticking around holding the persistent connections open 
and then  
consumes the data coming in before our handler can get it.    
Not really  
sure though as I'm not familiar with enough with the jetty 
code.  I tried  
tracing it with ethereal and all the data seems to be sent 
from the  
client to the server. 
I actually tried holding onto the server and just 
restarting it and the  
same problem occurs.   (basically, replace all the lines 
that look like  
server = createServer(); with server.start();)  I tried 
shutdowns, non graceful, etc..   Nothing seems to help. 

Attached Files:

Name Description Download Example jetty bug Download


Field Old Value Date By
artifact_group_id1.0Beta2006-04-26 23:39adisakala
artifact_group_idNone2006-03-31 15:45adisakala
File Added359: JettyBug.java2005-12-09 00:51dkulp
assigned_tonone2005-11-22 23:49adisakala

Copyright © 1999-2008, OW2 Consortium | contact | PS: You have a difficulty, a problem ? Please report an issue using your main OW2 account credentials