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

Advanced - Powered by Google


   
Log In
New Account
  
 
Home
My Page
Project Tree
Project Openings
Celtix ESB
          
 
 
Summary
Forums
Tracker
Lists
Tasks
News
Files
SVN
                
 

Tracker: Bugs

Submit New | Browse | Admin | ExportToXml

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

Date:
2005-11-22 18:31
Priority:
5
Submitted By:
Andrea Smyth (andrea)
Assigned To:
Daniel Kulp (dkulp)
Category:
None
State:
Open
Summary:
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 HTTPTransportTest.java 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

Followup

Message
Date: 2005-12-09 00:51
Sender: dkulp
Logged In: YES 
user_id=6784

  
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 
java.net.SocketTimeoutException: Read timed out 
        at java.net.SocketInputStream.socketRead0(Native 
Method) 
        at 
java.net.SocketInputStream.read(SocketInputStream.java:129) 
..... 
 
If I add a "connection.disconnect();" line to the end
of
runClient(), it  
works fine, but we'd obviously like to not have to do that 
for  
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 
graceful  
shutdowns, non graceful, etc..   Nothing seems to help. 
 
Thanks! 

Attached Files:

Name Description Download
JettyBug.java Example jetty bug Download

Changes:

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 | You have a difficulty, a problem ? Please report an issue using your OW2 forge account credentials