axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: [GUMP] Function Test Failure - Axis
Date Thu, 14 Jun 2001 21:41:54 GMT
+1

WRT the file transport in general, I'm not opposed to keeping it, but I'd
really like to see it get cleaned up if it's going to stick around.  There
should be better (i.e. some :)) synchronization between the two sides, and
the file-numbering scheme seems brittle.

I'd like to see it work as follows:

1) client creates "msg<n>.clock" file, where N is a random #
2) if creation failed because someone just created the same #, pick a new N

3) client writes xml to msg<n>.req.
4) client deletes msg<n>.clock

5) meanwhile, server is watching for any new msg<n>.req files.
6) when it sees one, it waits until the .clock file goes away,
   then reads the .req file into memory and processes the req
7) after successful processing (i.e. server doesn't crash) server
   creates "msg<n>.slock", then writes result into "msg<n>.res"
8) server deletes msg<n>.slock

Etc... You get the idea.

--G

> -----Original Message-----
> From: Sam Ruby [mailto:rubys@us.ibm.com]
> Sent: Thursday, June 14, 2001 4:37 PM
> To: axis-dev@xml.apache.org
> Subject: Re: [GUMP] Function Test Failure - Axis
> 
> 
> Rob Jellinghaus wrote:
> >
> > Can someone look and see why this happened?  This is 
> subsequent to my
> > checkin, but I did some post-checkin validation (I have a 
> separate copy of
> > the CVS which I use only to update-and-functional-test after every
> > checkin), so I don't think my code caused this.
> >
> > If this happened as a result of xmltoday going offline 
> temporarily again, I
> > am definitely going to remove the IBM test from 
> functional-tests, since
> > it's not acceptable to keep getting spurious hiccups like 
> this... you get
> > enough false alarms and you'll no longer know when you 
> really have a problem!
> 
> Unfortunately, the IBM test is already commented out.
> 
> From what I can tell, there are intermittent, timing problems with
> FileTransport.  They seem to happen more often on slower 
> machines (like the
> one that is doing the Gump runs).  They seem to happen more often with
> slower services (GetQuote("IBM")) than on faster services (GetQuote
> ("XXX")).
> 
> What I would like to do is to focus on factor out the 
> transport tests from
> the tests which are simply intended to test the end-to-end 
> operation of the
> system.
> 
> My thoughts at the moment are to move the bulk of the tests 
> to using the
> local transport - this is certainly the one that is least 
> prone to being
> influenced by other environmental factors.  As the local 
> transport does
> everything in one process and thread, this also opens up the 
> possibility of
> writing Junit style asserts on the "server" side too.
> 
> Don't misread my suggestion - I am not suggesting that we 
> eliminate any
> tests.  However, if we had local transport versions of the 
> existing tests,
> we could use the results to help narrow down where the problem is.
> 
> Make sense?
> 
> - Sam Ruby
> 

Mime
View raw message