You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Chris Newland <ch...@emorphia.com> on 2002/02/04 16:30:12 UTC

NPE in URLSource under high load

Hi All,

I'm encountering a null pointer exception in the
org.apache.cocoon.components.source.URLSource file when I run a stress test
of my Cocoon 2 system:

java.lang.NullPointerException
	at
org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:95)
	at
org.apache.cocoon.components.source.URLSource.getLastModified(URLSource.java
:110)
	at org.apache.cocoon.Cocoon.modifiedSince(Cocoon.java:376)
	at
org.apache.cocoon.servlet.CocoonServlet.getCocoon(CocoonServlet.java:919)
	at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:582)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
	at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)

<snip>

The code that throws the exception is: (from Cocoon 2.0 source, but
identical in CVS snapshot 04/Feb/2002 (apart from some boolean
optimizations))

  /**
     * Get the last modification date and content length of the source.
     * Any exceptions are ignored.
     */
    private void getInfos() {
        if (this.gotInfos == false) {
            if (this.isFile == true) {
                File file = new File(systemId.substring(FILE.length()));
                this.lastModificationDate = file.lastModified();
                this.contentLength = file.length();
            } else {
                try {
                    if (this.connection == null) {
                        this.connection = this.url.openConnection();
                        String userInfo = this.getUserInfo();
                        if (this.url.getProtocol().startsWith("http") ==
true && userInfo != null) {

this.connection.setRequestProperty("Authorization","Basic
"+this.encodeBASE64(userInfo));
                        }
                    }
                    this.lastModificationDate =
this.connection.getLastModified();
Line 95 ----->      this.contentLength = this.connection.getContentLength();
<------ NPE THROWN HERE
                } catch (IOException ignore) {
                    this.lastModificationDate = 0;
                    this.contentLength = -1;
                }
            }
            this.gotInfos = true;
        }
    }

The exception results in the Tomcat Internal Server Error 500 page being
shown and occurs about once in every 200 HTTP requests made by the stress
testing tool (Paessler Webserver Stress Tool 5.2 Enterprise Edition).

Looking at the code makes me think this might be a threading/synchronization
bug as IMHO 'this.connection' is null and should have thrown the NPE on the
previous line.

I'll do my best to trace the problem's origin but I'm out of the country for
3 weeks as of tomorrow.

Environment: SuSE 7.2, JDK 1.3.1_02, Cocoon 2.0 final, Tomcat 4.0.1,
mod_webapp, Apache 1.3.22

Stress testing tool is run from a remote client that hits the same 4 XSP
pages in random order simulating 5 concurrent users.

Best Regards,

Chris Newland



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: NPE in URLSource under high load

Posted by Chris Newland <ch...@emorphia.com>.
Hi Martin,

> -----Original Message-----
> From: Martin Holz [mailto:holz@fiz-chemie.de]
> Sent: 04 February 2002 16:36
> To: cocoon-dev@xml.apache.org
> Subject: Re: NPE in URLSource under high load
>
> Hi,
>
> Chris Newland wrote:
> > Hi All,
> >
> > I'm encountering a null pointer exception in the
> > org.apache.cocoon.components.source.URLSource file when I run a
> stress test
> > of my Cocoon 2 system:
> >
> > java.lang.NullPointerException
> > 	at
> >
> org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:95)
> > 	at
> >
> org.apache.cocoon.components.source.URLSource.getLastModified(URLS
> ource.jav
> >a
> > <snip>
>
> <snipped more>

<lots of snipping>

>
> If have noticed this from time to time too in Coccon 2.0 and 2.0.1.
> Are you sure, the exception is in
> this.connection.getContentLength() and not
> one line before in this.connection.getLastModified() ?
> I believe,  this.url.openConnection() returns null instead of
> throwing a IOException. Looks like a bug in the JDK.

The error page (and the log file) are reporting the exception as coming from
line 95. I've never known it to misreport the line number but nothing's
impossible.

Line 94: this.lastModificationDate = this.connection.getLastModified();
Line 95: this.contentLength = this.connection.getContentLength(); <------
NPE is thrown here

Assuming the NPE does occur on line 95, I would have to assume that multiple
threads are executing in this method and that the following situation occurs
(I'm on very thin ice here ;)

Thread A executes line 94
...
Thread B causes the value of 'this.connection' to be set to null
...
Thread A calls getContentLength() on 'this.connection' which causes the NPE

>
> However I have a different JDK:
> java version "1.3.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
> Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20000815 (JIT
> enabled:
> jitc))
>
> Don't know how the IBM JDK is related to Sun's  1.3.1_02.
>
> Enviroment: SuSE 7.1,Linux  2.4.0-64GB-SMP, Dual Processor Intel, JDK see
> above, Cocoon 2.01, Tomcat 4.0.1.

I'm using a dual-proc Intel system too. I read an article on VMs a while
back warning about the dangers of assuming that threading behaviour is the
same between uniprocessor and multiprocessor systems. Perhaps this is a
manifestation of this problem.

>
> Problem seems to happen more often with IE 5.5 than with Mozilla
> 0.97, maybe
> because IE is faster. Reloading the page always solves the problem.
>
> Maybe, Cocoon should catch not only the IOException, but also the NPE.

I guess this would work but I don't think its a good idea if the real
problem is in CocoonServlet.

>
> --
> Martin Holz  <ho...@fiz-chemie.de>  phone: 0049-30-39977 218
> FIZ CHEMIE BERLIN
>

Best Regards,

Chris



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: NPE in URLSource under high load

Posted by Martin Holz <ho...@fiz-chemie.de>.
Hi,

Chris Newland wrote:
> Hi All,
>
> I'm encountering a null pointer exception in the
> org.apache.cocoon.components.source.URLSource file when I run a stress test
> of my Cocoon 2 system:
>
> java.lang.NullPointerException
> 	at
> org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:95)
> 	at
> org.apache.cocoon.components.source.URLSource.getLastModified(URLSource.jav
>a
> <snip>

<snipped more>

> The code that throws the exception is: (from Cocoon 2.0 source, but
> identical in CVS snapshot 04/Feb/2002 (apart from some boolean
> optimizations))
>
>   /**
>      * Get the last modification date and content length of the source.
>      * Any exceptions are ignored.
>      */
>     private void getInfos() {
>         if (this.gotInfos == false) {
>             if (this.isFile == true) {
>                 File file = new File(systemId.substring(FILE.length()));
>                 this.lastModificationDate = file.lastModified();
>                 this.contentLength = file.length();
>             } else {
>                 try {
>                     if (this.connection == null) {
>                         this.connection = this.url.openConnection();
>                         String userInfo = this.getUserInfo();
>                         if (this.url.getProtocol().startsWith("http") ==
> true && userInfo != null) {
>
> this.connection.setRequestProperty("Authorization","Basic
> "+this.encodeBASE64(userInfo));
>                         }
>                     }
>                     this.lastModificationDate =
> this.connection.getLastModified();
> Line 95 ----->      this.contentLength =
> this.connection.getContentLength(); <------ NPE THROWN HERE
>                 } catch (IOException ignore) {
>                     this.lastModificationDate = 0;
>                     this.contentLength = -1;
>                 }
>             }
>             this.gotInfos = true;
>         }
>     }
>
> The exception results in the Tomcat Internal Server Error 500 page being
> shown and occurs about once in every 200 HTTP requests made by the stress
> testing tool (Paessler Webserver Stress Tool 5.2 Enterprise Edition).
>
> Looking at the code makes me think this might be a
> threading/synchronization bug as IMHO 'this.connection' is null and should
> have thrown the NPE on the previous line.
>
> I'll do my best to trace the problem's origin but I'm out of the country
> for 3 weeks as of tomorrow.
>
> Environment: SuSE 7.2, JDK 1.3.1_02, Cocoon 2.0 final, Tomcat 4.0.1,
> mod_webapp, Apache 1.3.22
>
> Stress testing tool is run from a remote client that hits the same 4 XSP
> pages in random order simulating 5 concurrent users.
>


If have noticed this from time to time too in Coccon 2.0 and 2.0.1.
Are you sure, the exception is in  this.connection.getContentLength() and not 
one line before in this.connection.getLastModified() ?
I believe,  this.url.openConnection() returns null instead of
throwing a IOException. Looks like a bug in the JDK.

However I have a different JDK:
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Classic VM (build 1.3.0, J2RE 1.3.0 IBM build cx130-20000815 (JIT enabled: 
jitc))

Don't know how the IBM JDK is related to Sun's  1.3.1_02.

Enviroment: SuSE 7.1,Linux  2.4.0-64GB-SMP, Dual Processor Intel, JDK see 
above, Cocoon 2.01, Tomcat 4.0.1.

Problem seems to happen more often with IE 5.5 than with Mozilla 0.97, maybe 
because IE is faster. Reloading the page always solves the problem.

Maybe, Cocoon should catch not only the IOException, but also the NPE.

--
Martin Holz  <ho...@fiz-chemie.de>  phone: 0049-30-39977 218 
FIZ CHEMIE BERLIN




  

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: NPE in URLSource under high load

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:

>>From: Chris Newland [mailto:chris.newland@emorphia.com]
>>
>>Hi All,
>>
>>I'm encountering a null pointer exception in the
>>org.apache.cocoon.components.source.URLSource file when I run a stress
>>
>test
>
>>of my Cocoon 2 system:
>>
>>java.lang.NullPointerException
>>	at
>>
>org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:95
>)
>
>>	at
>>
>org.apache.cocoon.components.source.URLSource.getLastModified(URLSource.
>java
>
>>:110)
>>	at org.apache.cocoon.Cocoon.modifiedSince(Cocoon.java:376)
>>	at
>>
> 
><snip>
> 
>
>>Looking at the code makes me think this might be a
>>
>threading/synchronization
>
>>bug as IMHO 'this.connection' is null and should have thrown the NPE
>>
>on the
>
>>previous line.
>>
>
>It *is* threading bug. URLSource is not intended to be used by multiple
>threads simultaneously. However, Cocoon.java uses it exactly this way.
>
>
>>I'll do my best to trace the problem's origin but I'm out of the
>>
>country for
>
>>3 weeks as of tomorrow.
>>
>
>The quick (==bad performance) fix will be to surround call with
>synchronized:
>
>    public boolean modifiedSince(long date) {
>        synchronized(this.configurationFile) {
>            this.configurationFile.refresh();
>            return date < this.configurationFile.getLastModified();
>        }
>    }
>
>The better solution is to use ActiveMonitor. There was a discussion
>about it but I do not remember the results of it.
>
>Regards,
>Vadim
>
I made a quick update using DelayedSourceWrapper : getLastModified() is 
called only once per second (we should make it configurable) and is in a 
synchronized block.

This solves the concurrency issue at the price of one synchronized 
statement each second, which should be acceptable ;)

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: NPE in URLSource under high load

Posted by Gerhard Froehlich <g-...@gmx.de>.
Vadim,

</skip>

>The better solution is to use ActiveMonitor. There was a discussion
>about it but I do not remember the results of it.

The result of this long debate was, that ActiveMonitor is an overkill
for that and we use Sylvain idea instead. Buuut I'm not that convinced
;-), as normal.

  ~Gerhard
 
"When I die, I want to go just like my Grandfather,
in my sleep.
Not like the screaming passengers in the car
he was driving."
(Ancient Chinese Proverb)


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: NPE in URLSource under high load

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Chris Newland [mailto:chris.newland@emorphia.com]
> 
> Hi All,
> 
> I'm encountering a null pointer exception in the
> org.apache.cocoon.components.source.URLSource file when I run a stress
test
> of my Cocoon 2 system:
> 
> java.lang.NullPointerException
> 	at
>
org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:95
)
> 	at
>
org.apache.cocoon.components.source.URLSource.getLastModified(URLSource.
java
> :110)
> 	at org.apache.cocoon.Cocoon.modifiedSince(Cocoon.java:376)
> 	at
 
<snip>
 
> Looking at the code makes me think this might be a
threading/synchronization
> bug as IMHO 'this.connection' is null and should have thrown the NPE
on the
> previous line.

It *is* threading bug. URLSource is not intended to be used by multiple
threads simultaneously. However, Cocoon.java uses it exactly this way.


> I'll do my best to trace the problem's origin but I'm out of the
country for
> 3 weeks as of tomorrow.

The quick (==bad performance) fix will be to surround call with
synchronized:

    public boolean modifiedSince(long date) {
        synchronized(this.configurationFile) {
            this.configurationFile.refresh();
            return date < this.configurationFile.getLastModified();
        }
    }

The better solution is to use ActiveMonitor. There was a discussion
about it but I do not remember the results of it.

Regards,
Vadim


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org