axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Nagy <>
Subject Re: svn commit: r450121 - in /webservices/axis2/trunk/java/modules: integration/test/org/apache/axis2/engine/ kernel/src/org/apache/axis2/context/ kernel/src/org/apache/axis2/engine/ kernel/src/org/apache/axis2/handlers/ kernel/src/org/apache/axis2/transpo...
Date Wed, 27 Sep 2006 04:45:19 GMT
Hi Sanjiva,

While the JIRA issue may have had "cleanup" in the title, points 2 and 3
of the issue (and also Deepal's later comments) deal with what I fixed.

I'm not sure that I understand why you say "the impl that has been
committed is going to slow Axis2 down big time."  It makes one extra
method invocation to each phase, which in turn makes one extra method
call to each handler that was previously invoked for each message flow.
If the handlers don't need to do anything, then that time is negligible
-- if they do need to do something, then they need to do the work, and
spend the time for a reason.


On Wed, 2006-09-27 at 09:58 +0530, Sanjiva Weerawarana wrote:
> Hi Bill,
> > This change actually addresses part of a JIRA issue that was marked as a
> > "blocker" (AXIS2-653), and according to Thilina's post these are to be
> > fixed before the release.  (I will address the other part as well, but
> > there were two separate issues so I separated this one out and tackled
> > if first.)  
> I think the original issue which was marked a blocker was that cleanup()
> wasn't called. That's not what's implemented by this patch. 
> I am not opposed to solving the problem you want to solve with this
> patch but the impl that has been committed is going to slow Axis2 down
> big time. We have discussed the problem but IIRC didn't come to a
> consensus on the solution. I'd really rather work thru this more before
> we do it. If a performance degrading solution is the only one then I'd
> like to think long and hard about it before doing it. 
> We've gotten hammered on the user mailing list for having stuff that is
> not fully baked in a major release. Doing this now (literally 2 days
> before the planned code freeze) is going to put in something that hasn't
> been tried, tested and proven into a major release. 
> So, I'd like to request that we remove the blocker status on this issue
> and revert this patch. My apologies but I'm not lifting my -1 on this
> patch.
> I guess I should be arguing with the release manager for leaving this as
> a blocker! 
> Let's pick it up after 1.1 and sort it out. ApacheCon US would be a
> great time to do it if you'll be around there.
> Sanjiva.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message