Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <200008281515.JAA27033@amon.Central.Sun.COM>
Date: Mon, 28 Aug 2000 09:15:08 -0600 (MDT)
From: Arieh Markel <Arieh.Markel@central.sun.com>
Reply-To: Arieh Markel <Arieh.Markel@central.sun.com>
Subject: Re: More problems with migration to 3.2
To: tomcat-dev@jakarta.apache.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: HePLjqrkyT2az3cz5vLy0A==


> Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
> X-No-Archive: yes
> list-help: <mailto:tomcat-dev-help@jakarta.apache.org>
> list-unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> list-post: <mailto:tomcat-dev@jakarta.apache.org>
> Delivered-To: mailing list tomcat-dev@jakarta.apache.org
> From: cmanolache@yahoo.com
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: More problems with migration to 3.2
> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N
> 
> Ok, I know it's late - but can you try one more:
> 
> - in ResponseImpl.finish():
> check   isUsingWriter, writer ( must be true, !=null)
> check bBuffer ( must be null )

(I incorporated the OutputBuffer that Alex suggested. That did not help.

So, I proceeded to instrument as Costin mentions.

The results are:

	. isUsingWriter = false
	. isStarted     = false
	. writer        = null
	. oBuffer	= not null
	
(bBuffer is no longer used, oBuffer is used instead).

Not content with that information, I also implemented a 'getCount()' method
on OutputBuffer. I proceeded to print out the count on the Response.finish()
method, only to find out that the length is zero.

----

Further, I proceeded to instrument the OutputBuffer class to see what
the conditions are for the buffer state at the time of invocation of
finish(). The output indicates that it is in INITIAL_STATE (on which the
OutputBuffer performs a NO-OP).

I also instrumented OutputBuffer.recycle() to see when that happens too.

----

Interestingly enough, I can see that the behavior is not totally consistent.
For example, my application has a servlet called 'simpleLogViewer' which
is expected to generate output to a specific frame in the HTML page.

There was a case in my run/debug/instrumentation that it managed to
generate output, while in the rest of them it produced no output.

In general, in all those cases where output is not generated, I see that
the ServletWriterFacade.println() method gets invoked, but there is
no corresponding HttpResponseAdapter.doWrite() call.

In such circumstances, the Response.finish() method is invoked, but the
buffer has already been reset (it is in INITIAL_STATE).

----

Just an aside on my investigation.

While reading the code of OutputBuffer, there is a chance that writing
can be done while being in INITIAL_STATE, which will prevent flushing
(I haven't seen this happening, but the fact that the
'public void writeBytes(byte b[], int off, int len)' method is public
allows its invocation directly. The method does not implement the
logic of:
	if( state==CHAR_STATE )
            flushChars();
        state=BYTE_STATE;
        
(it probably assumes always called from within the class).

----

I hope that the information collected helps.


Arieh
	 

> 
> If ContextManager.flush is called then finish will
> be called.
> 
> The problem seems to be that the writer is not flushed.
> 
> ( Ok, the good news is that in 3.3 the output system was
> greatly simplified - there is only one OutputBuffer and
> we avoid most of the ugly stream/writer code )
> 
> Costin
> 
> > I performed the following instrumentation:
> >
> >         service/http/HttpResponseAdapter: I added a flushBuffer() method
> >                 on which I print the fact that I got there and invoke
> >                 the superclass (Response) method.
> >                 I also instrumented the doWrite() method to output the
> >                 number of bytes being printed.
> >
> >         core/ContextManager: I add print statement to indicate that
> >                 request servicing had finished
> >
> > What I found is the following:
> >
> > . the ContextManager finished processing the request
> > . the Adapter flushBuffer method was never called.
> > . the Adapter doWrite() method was not called consistently (it was called
> >   to present the initial login screen, it was called to display the next
> >   page, it failed to be called when the output generated was dynamically
> >   generated by a servlet.
> >
> > It is not clear to me that flush is done through the adapter.
> >
> > As a remark, I would add that all writes are done through the servlet's
> > HttpServletResponse.getPrintWriter.
> >
> > Arieh
> >
> > >
> > > It seems like a serious problem...
> > >
> > > Costin
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> > --
> >  Arieh Markel                           Sun Microsystems Inc.
> >  Network Storage                        500 Eldorado Blvd. MS UBRM11-194
> >  e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
> >  Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
> >  (e-mail me with subject SEND PUBLIC KEY to get public key)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

--
 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)