NullPointerException - org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130)
Hi, I've implemented Axis2 Web Services in Tomcat 5.5.26 and at times of high load (when there are several web service client requests coming in to Tomcat), Tomcat starts throwing following NPE: java.lang.NullPointerException at org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130) Is there a solution for the above exception? N.B.: I tried setting the system property ... org.apache.catalina.connector.RECYCLE_FACADES=true ... in vain. Also I tried deploying my Axis2 code on Tomcat 6.0.20 and observed that these NPE do occur but with less frequency. Any help on this will be appreciated. -Nikhil -- View this message in context: http://www.nabble.com/NullPointerException---org.apache.tomcat.util.http.MimeHeaders.clear%28MimeHeaders.java%3A130%29-tp24950134p24950134.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r803803 - /tomcat/native/trunk/native/build/tcnative.m4
Author: jfclere
Date: Thu Aug 13 07:58:04 2009
New Revision: 803803
URL: http://svn.apache.org/viewvc?rev=803803&view=rev
Log:
Add detection of the macosx jvm.
BTW: Where r801544 was going...
Modified:
tomcat/native/trunk/native/build/tcnative.m4
Modified: tomcat/native/trunk/native/build/tcnative.m4
URL:
http://svn.apache.org/viewvc/tomcat/native/trunk/native/build/tcnative.m4?rev=803803&r1=803802&r2=803803&view=diff
==
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Thu Aug 13 07:58:04 2009
@@ -117,13 +117,13 @@
# JAVA_PLATFORM
AC_MSG_CHECKING([Try to guess JDK location])
- for JAVA_PREFIX in /usr/local /usr/local/lib /usr /usr/lib /opt
/usr/java ; do
+ for JAVA_PREFIX in /usr/local /usr/local/lib /usr /usr/lib /opt
/usr/java /System/Library/Frameworks/JavaVM.framework/Versions/ ; do
for JAVA_PLATFORM in 6 5 4 3 2 ; do
- for subversion in .9 .8 .7 .6 .5 .4 .3 .2 .1 "" ; do
+ for subversion in .9 .8 .7 .6 .5 .4 .3 .2 .1 .0 "" ; do
-for VARIANT in IBMJava2- java java- jdk jdk-; do
+for VARIANT in IBMJava2- java java- jdk jdk- ""; do
GUESS="${JAVA_PREFIX}/${VARIANT}1.${JAVA_PLATFORM}${subversion}"
dnl AC_MSG_CHECKING([${GUESS}])
if test -d "${GUESS}/bin" & test -d "${GUESS}/include" ; then
@@ -131,6 +131,11 @@
AC_MSG_RESULT([${GUESS}])
break
fi
+ if test -d "${GUESS}/Commands" & test -d "${GUESS}/Headers" ;
then
+JAVA_HOME="${GUESS}"
+AC_MSG_RESULT([${GUESS}])
+break
+ fi
done
if test -n "${JAVA_HOME}" ; then
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Taglibs SVN migration to Tomcat
Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite -> tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
about setLoopbackMode of McastServiceImpl of tomcat tribes
Hi. I use tomcat tribes to develop my application resently, and I find this line in the source code of the class, org.apache.catalina.tribes.membership.McastServiceImpl, at line 202 (I use apache-tomcat-6.0.20 source code): socket.setLoopbackMode(true);//hint that we don't need loop back messages I think it is better to setLoopbackMode through a construtor's argument or a property. Because I really need debug my program on my single development PC sometimes, or need to run two process of my application to get higher availability. BTW, I think sun's naming way is ugly, about socket.setLoopbackMode at least. When I see this line, I really think it is to enable socket's LoopbackMode if no the following comment, but actually the name of the parameter needed by setLoopbackMode is "disable". thanks. -- Jeff Yang - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On 08/13/2009 10:48 AM, Henri Yandell wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite -> tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. +1 Cheers Jean-Frederic Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NullPointerException - org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130)
Rastogi Nikhil wrote: > Hi, > > I've implemented Axis2 Web Services in Tomcat 5.5.26 and at times of high > load (when there are several web service client requests coming in to > Tomcat), Tomcat starts throwing following NPE: > > java.lang.NullPointerException > at > org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130) > > Is there a solution for the above exception? > > N.B.: I tried setting the system property ... >org.apache.catalina.connector.RECYCLE_FACADES=true > ... in vain. > Also I tried deploying my Axis2 code on Tomcat 6.0.20 and observed that > these NPE do occur but with less frequency. > > Any help on this will be appreciated. This is a question for the users list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
Henri Yandell wrote: > Post discussion between Tomcat PMC and Jakarta PMC (with myself as the > go between), the Jakarta Taglibs subproject is going to move over to > Tomcat land. Chiefly this means: > site/ [subsite -> tomcat.apache.org/taglibs/] > Anyway - all open to discussion + debate; let me know what works best > from this list's point of view. +1 Longer term, it might be worth merging the taglibs site into the main tomcat site. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
+1 welcome aboard, Filip On 08/13/2009 02:48 AM, Henri Yandell wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite -> tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r803951 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Thu Aug 13 17:20:27 2009 New Revision: 803951 URL: http://svn.apache.org/viewvc?rev=803951&view=rev Log: vote Modified: tomcat/tc5.5.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=803951&r1=803950&r2=803951&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Thu Aug 13 17:20:27 2009 @@ -80,7 +80,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=41824 Need to use canonical rather than binary form when writing code http://svn.apache.org/viewvc?rev=797607&view=rev - +1: markt, rjung + +1: markt, rjung, kkolinko -1: * Improve build.properties comment in ant build files. Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=803951&r1=803950&r2=803951&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Aug 13 17:20:27 2009 @@ -192,7 +192,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=41824 Need to use canonical rather than binary form when writing code http://svn.apache.org/viewvc?rev=797607&view=rev - +1: markt, rjung + +1: markt, rjung, kkolinko -1: * Improve build.properties comment in ant build files. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On Thu, Aug 13, 2009 at 4:48 AM, Henri Yandell wrote: > Post discussion between Tomcat PMC and Jakarta PMC (with myself as the > go between), the Jakarta Taglibs subproject is going to move over to > Tomcat land. Chiefly this means: > > * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. > * RDC Taglib. > * An in development 'extended' taglib. > All looks good -- thanks for CC'ing me, but you don't have to (I've been subscribed to Tomcat dev + user for many years now). -Rahul - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
>
> Other option is to use required.secret instead requiredSecret
> Much easier because requiredSecret isn't document, so one
> can only find it browsing the source code.
>
> However dunno how to make it using current property set/get methods
>
I have just noticed - the following patch (as currently proposed for
tc6.0) is an example of implementing such a dot property
("socket.unlockTimeout"):
* Improve NIO connector shutdown time by doing shutdowns in parallel
and with a timeout
http://svn.apache.org/viewvc?view=rev&revision=791914
I have not dug into details yet, though.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
And I just added myself back in, but with my employer-independent email... On Thu, Aug 13, 2009 at 1:37 PM, Rahul Akolkar wrote: > On Thu, Aug 13, 2009 at 4:48 AM, Henri Yandell wrote: >> Post discussion between Tomcat PMC and Jakarta PMC (with myself as the >> go between), the Jakarta Taglibs subproject is going to move over to >> Tomcat land. Chiefly this means: >> >> * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. >> * RDC Taglib. >> * An in development 'extended' taglib. >> > > > All looks good -- thanks for CC'ing me, but you don't have to (I've > been subscribed to Tomcat dev + user for many years now). > > -Rahul -- Kris Schneider - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
On 13/08/09 19:43, Konstantin Kolinko wrote:
Other option is to use required.secret instead requiredSecret
Much easier because requiredSecret isn't document, so one
can only find it browsing the source code.
However dunno how to make it using current property set/get methods
I have just noticed - the following patch (as currently proposed for
tc6.0) is an example of implementing such a dot property
("socket.unlockTimeout"):
* Improve NIO connector shutdown time by doing shutdowns in parallel
and with a timeout
http://svn.apache.org/viewvc?view=rev&revision=791914
I have not dug into details yet, though.
It looks like magic ;)
I always thought that setName(...) reflects name="...",
now it seems it's possible to have setName(...) and socket.name="..."
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[proposal] remove worker based connector thread pools in trunk
Here is why I think its good
1. Current pools can't shrink, so when peak has been hit, that's where
were at
2. Current pools are unfair, synchronized (workers) { workers.wait() },
executors are a bit more fair since they only hold a lock for a short period
3. Reduce duplicate code
4. Executors provide more flexibility
5. I have not found a performance difference anymore
6. Async implementation becomes much easier, since
AsyncContext.dispatch() is easily handed off to an executor and
releasing application thread. Otherwise we have to add an executor on
top of the existing thread pool, which is doable, just not pragmatic
best
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
On 13.08.2009 20:31, Mladen Turk wrote:
> On 13/08/09 19:43, Konstantin Kolinko wrote:
>>> Other option is to use required.secret instead requiredSecret
>>> Much easier because requiredSecret isn't document, so one
>>> can only find it browsing the source code.
>>>
>>> However dunno how to make it using current property set/get methods
>>>
>>
>> I have just noticed - the following patch (as currently proposed for
>> tc6.0) is an example of implementing such a dot property
>> ("socket.unlockTimeout"):
>>
>> * Improve NIO connector shutdown time by doing shutdowns in parallel
>>and with a timeout
>>http://svn.apache.org/viewvc?view=rev&revision=791914
>>
>> I have not dug into details yet, though.
>>
>
> It looks like magic ;)
> I always thought that setName(...) reflects name="...",
> now it seems it's possible to have setName(...) and socket.name="..."
A similar feature is used in the cluster. The cluster configuration has
elements for the Cluster, Membership, Sender and Receiver, but not e.g.
for the Manager. If you want to set property xxx on the cluster manager,
you can configure manager.xxx inside the Cluster element.
So the part before the dot should express some kind of related class the
param should be passed to. That would be true for request.secret, but
not for required.secret.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r804057 - /tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Author: fhanik
Date: Thu Aug 13 23:10:40 2009
New Revision: 804057
URL: http://svn.apache.org/viewvc?rev=804057&view=rev
Log:
Deserialize with the webapp classloader as the context classloader
Modified:
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=804057&r1=804056&r2=804057&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Thu Aug
13 23:10:40 2009
@@ -169,12 +169,12 @@
try {
lock();
ReplicationStream stream = ( (ClusterManager)
getManager()).getReplicationStream(diff, offset, length);
-getDeltaRequest().readExternal(stream);
ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
try {
ClassLoader[] loaders = getClassLoaders();
if (loaders != null && loaders.length > 0)
Thread.currentThread().setContextClassLoader(loaders[0]);
+getDeltaRequest().readExternal(stream);
getDeltaRequest().execute(this,
((ClusterManager)getManager()).isNotifyListenersOnReplication());
} finally {
Thread.currentThread().setContextClassLoader(contextLoader);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r804058 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik Date: Thu Aug 13 23:12:36 2009 New Revision: 804058 URL: http://svn.apache.org/viewvc?rev=804058&view=rev Log: proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=804058&r1=804057&r2=804058&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Aug 13 23:12:36 2009 @@ -297,3 +297,12 @@ http://people.apache.org/~kkolinko/patches/2009-08-13_bug45403-tc6.patch +1: kkolinko -1: + +* Perform deserialization with the context class loader set. + This ensures that code that actually executes Class.forName(...,classloader) during this phase + works properly. + http://svn.apache.org/viewvc?rev=804057&view=rev + +1: fhanik + -1: + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
2009/8/13 Mladen Turk :
> On 13/08/09 19:43, Konstantin Kolinko wrote:
>>>
>>> Other option is to use required.secret instead requiredSecret
>>> Much easier because requiredSecret isn't document, so one
>>> can only find it browsing the source code.
>>>
>>> However dunno how to make it using current property set/get methods
>>>
>>
>> I have just noticed - the following patch (as currently proposed for
>> tc6.0) is an example of implementing such a dot property
>> ("socket.unlockTimeout"):
>>
>> * Improve NIO connector shutdown time by doing shutdowns in parallel
>> and with a timeout
>> http://svn.apache.org/viewvc?view=rev&revision=791914
>>
>> I have not dug into details yet, though.
>>
>
> It looks like magic ;)
> I always thought that setName(...) reflects name="...",
> now it seems it's possible to have setName(...) and socket.name="..."
>
... The implementation, in this case, is in NioEndpoint#setProperty()
{
final String selectorPoolName = "selectorPool.";
final String socketName = "socket.";
if (name.startsWith(selectorPoolName)) {
return IntrospectionUtils.setProperty(...);
} else if (name.startsWith(socketName)) {
return IntrospectionUtils.setProperty(...);
} else {
return IntrospectionUtils.setProperty(this,name,value);
}
}
and it is o.a.tomcat.util.IntrospectionUtils#setProperty(..) that
looks for the "setProperty" method if explicit setter is not
available.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
