From davisamy@example.org Tue Oct 02 20:05:12 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 112 invoked from network); 2 Oct 2007 20:05:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 2 Oct 2007 20:05:11 -0000
Received: (qmail 56617 invoked by uid 500); 2 Oct 2007 20:05:00 -0000
Delivered-To: davisamy@example.org
Received: (qmail 56591 invoked by uid 500); 2 Oct 2007 20:05:00 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 56313 invoked by uid 99); 2 Oct 2007 20:05:00 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 13:04:59 -0700
X-ASF-Spam-Status: No, hits=-4.0 required=10.0
	tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of davisamy@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO sj-iport-1.cisco.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Oct 2007 20:04:58 +0000
X-IronPort-AV: E=Sophos;i="4.21,221,1188802800"; 
   d="scan'208";a="21219592"
Received: from sj-dkim-4.cisco.com ([83.161.120.155])
  by sj-iport-1.cisco.com with ESMTP; 02 Oct 2007 13:04:37 -0700
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [83.161.120.155])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l92K4bEf027044
	for <davisamy@example.org>; Tue, 2 Oct 2007 13:04:37 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [83.161.120.155])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l92K4beB020360
	for <davisamy@example.org>; Tue, 2 Oct 2007 20:04:37 GMT
Received: from xmb-sjc-22c.amer.cisco.com ([83.161.120.155]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC949-687-9231);
	 Tue, 2 Oct 2007 13:04:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: EMPTY_DOC thread stability issues
Date: Tue, 2 Oct 2007 13:04:32 -0700
Message-ID: <davisamy@example.org>
In-Reply-To: <davisamy@example.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EMPTY_DOC thread stability issues
Thread-Index: Acf1If5IMggk2lexRQiIzjI3mx3bVAQDTTjw
From: "Vinh Nguyen (vinguye2)" <davisamy@example.org>
To: <davisamy@example.org>
X-OriginalArrivalTime: 02 Oct 2007 20:04:34.0722 (UTC) FILETIME=[73F6E020:01C8052F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5159; t=1191355477; x=1192219477;
	c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; davisamy@example.org;
	z=From:=20=22Vinh=20Nguyen=20(vinguye2)=22=20<davisamy@example.org>
	|Subject:=20RE=3A=20EMPTY_DOC=20thread=20stability=20issues
	|Sender:=20;
	bh=QgLDUk3jc1WiSYXwK+6vrWzOxvrwIFId442zKNWLRNI=;
	b=f4WJFfO60C6mT3GM6MyNttRDGNa1ZqQ5Rnyehd3V5Q5kuBBvLC5nu4kmWbk8/R6oWn+6L/hH
	b/O3LBPjDPlh+CiApG4+bdLrrfCRrKxwB2iGpjBaCUYnQgj4VZen9Wsj;
Authentication-Results: sj-dkim-4; davisamy@example.org; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
X-Virus-Checked: Checked by ClamAV on apache.org

Any idea when the overall solution will be tested and an official patch =
released?  I think this is a critical issue for mostly everyone.
=20

-----Original Message-----
From: Oliver Waeldrich [mailto:davisamy@example.org]=20
Sent: Wednesday, September 12, 2007 2:47 AM
To: davisamy@example.org
Subject: RE: EMPTY_DOC thread stability issues

Hi all,

I have checked the proposal of Chris and I really like it. I think the =
best way to proceed is to refactor the XmlUtils class a bit. The =
refatorisation of XmlUtils means that each Thread will have its own =
instance of a document builder. New documents are created by this =
instance. Therefore a new method getDocumentBuilder() is needed. =
Furthermore, the usage of createBuilder() in XmlUtils should be replaced =
by getDocumentBuilder() method. =20

    static final ThreadLocal tls =3D new ThreadLocal(){
        protected Object initialValue() {
           // the method createBuilder needs to be synchronized=20
           return createBuilder();
        }
    };
   =20
    private static DocumentBuilder getDocumentBuilder() {
        return (DocumentBuilder)tls.get();
    }

This also means that the representations of EMPTY_DOC in the Muse code =
can be replaced with createDocument() without experiencing a big =
performance loss. With the changes proposed/done by Vinh I think the =
major parts of the problem should be solved.

Thanks to Chris, Rich and Vinh for the fruitful discussion.

Oliver

-------- Original-Nachricht --------
> Datum: Thu, 6 Sep 2007 17:00:09 +0200
> Von: davisamy@example.org
> An: davisamy@example.org
> Betreff: RE: EMPTY_DOC thread stability issues

> Hi all,
>=20
> @Oliver, I've tried running the tests but I get NPE's from both the=20
> threadlocal version and the current version.  Have I run something=20
> incorrectly?
>=20
> java.lang.NullPointerException
> 	at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source)
> 	at org.apache.xerces.dom.ParentNode.item(Unknown Source)
> 	at
> org.apache.muse.test.thread.local.TestEndpointReference.<init>(TestEnd
> po
> intReference.java:197)
> 	at
> org.apache.muse.test.thread.local.TestThread.run(TestThread.java:60)
> java.lang.NullPointerException
> 	at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source)
> 	at org.apache.xerces.dom.ParentNode.item(Unknown Source)
> 	at
> org.apache.muse.test.thread.local.TestEndpointReference.<init>(TestEnd
> po
> intReference.java:197)
> 	at
> org.apache.muse.test.thread.local.TestThread.run(TestThread.java:60)
>=20
> the shared epr and seperate docs versions shows no errors. =20
>=20
> The seperate doc one takes for ever, quite a performance hit on both=20
> the synchronized for getLocalDoc, which shouldn't be necessary since=20
> newInstance is threadsafe on DocumentBuilderFactory and the=20
> createDocument.  I replaced the getLocalDoc with :
>=20
> 	static final ThreadLocal tls =3D new ThreadLocal(){
> 		protected Object initialValue() {
> 			 DocumentBuilderFactory factory =3D
> DocumentBuilderFactory.newInstance();
> 		     factory.setNamespaceAware(true);
> 		     factory.setIgnoringComments(true);
> 		     try
> 		        {
> 		            return factory.newDocumentBuilder();
> 		        }
> 		        catch (ParserConfigurationException error)
> 		        {
> 		            throw new
> RuntimeException(error.getMessage(), error);
> 		        }
> 		}
> 	};
> =09
>     public static Document getLocalDoc() {
>     	return ((DocumentBuilder)tls.get()).newDocument();
> 	}
>=20
> and it improved the performance considerably (equal with the current=20
> solution, but correct).  Creating new documentbuilder factories is=20
> extremly expensive, jar lookups resource creation, class loading etc.
>=20
> cheers,
> Chris
>=20
> PS A drop in replacement of a customised axis 1.4 - does namespaces=20
> etc correctly - runs in 128 secs (half+ the speed of the current buggy =

> impl).  If others are interested this version doesn't suffer threading =

> issues on read only, it just creates a few too many things but it=20
> could be stripped down into a usable general dom.
> PPS I'm going to start working with Vinhs tests now.
>=20
> -----Original Message-----
> From: Vinh Nguyen (vinguye2) [mailto:davisamy@example.org]
> Sent: Thursday, September 06, 2007 3:45 AM
> To: davisamy@example.org
> Subject: RE: EMPTY_DOC thread stability issues
>=20
> My test case has been posted to JIRA Muse-270:
>=20
> https://issues.apache.org/jira/browse/MUSE-270
> =20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: davisamy@example.org
> For additional commands, e-mail: davisamy@example.org

--=20



Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org

---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


From davisamy@example.org Wed Oct 03 11:57:31 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 15882 invoked from network); 3 Oct 2007 11:57:30 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 3 Oct 2007 11:57:30 -0000
Received: (qmail 40895 invoked by uid 500); 3 Oct 2007 11:57:19 -0000
Delivered-To: davisamy@example.org
Received: (qmail 40866 invoked by uid 500); 3 Oct 2007 11:57:19 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 40855 invoked by uid 99); 3 Oct 2007 11:57:19 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Oct 2007 04:57:19 -0700
X-ASF-Spam-Status: No, hits=-2.8 required=10.0
	tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [83.161.120.155] (HELO mrp.swissptt.ch) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Oct 2007 11:57:20 +0000
Received: from sxmcmp01.corproot.net (SXMCMP01.corproot.net [83.161.120.155])
	by mrp.swissptt.ch with ESMTP id l93BtsJJ029112
	for <davisamy@example.org>; Wed, 3 Oct 2007 13:55:55 +0200 (MEST)
Received: from sxsmtp01.corproot.net ([83.161.120.155]) by sxmcmp01.corproot.net with InterScan Message Security Suite; Wed, 03 Oct 2007 13:55:54 +0200
Received: from sxmbx06.corproot.net ([83.161.120.155]) by sxsmtp01.corproot.net with Microsoft SMTPSVC949-687-9231);
	 Wed, 3 Oct 2007 13:55:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: EMPTY_DOC thread stability issues
Date: Wed, 3 Oct 2007 13:55:50 +0200
Message-ID: <davisamy@example.org>
In-Reply-To: <davisamy@example.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: EMPTY_DOC thread stability issues
Thread-Index: Acf1If5IMggk2lexRQiIzjI3mx3bVAQDTTjwACEo3CA=
References: <davisamy@example.org> <davisamy@example.org>
From: <davisamy@example.org>
To: <davisamy@example.org>
X-OriginalArrivalTime: 03 Oct 2007 11:55:53.0850 (UTC) FILETIME=[59C69DA0:01C805B4]
X-Virus-Checked: Checked by ClamAV on apache.org

Has anyone else tested your producer / consumer test?  We really need =
people to do that.  Simple, expected, fixes are to move to =
getfirstchild/nextsibling and the tls approach (could use a pool for =
that too).  But we need to make sure that at least one other person can =
repeat your findings before anything can be deemed to be solved.

I could repeat Olivers tests on a single cpu machine but I think yours =
require at least 2 cpus to cause the issues.  (It may not even be the =
same issue of course).

I can provide a patch for both fairly quickly but we really need at =
least two different setups for your tests to verify that the solution is =
complete.

-----Original Message-----
From: Vinh Nguyen (vinguye2) [mailto:davisamy@example.org]=20
Sent: Tuesday, October 02, 2007 10:05 PM
To: davisamy@example.org
Subject: RE: EMPTY_DOC thread stability issues

Any idea when the overall solution will be tested and an official patch =
released?  I think this is a critical issue for mostly everyone.
=20

-----Original Message-----
From: Oliver Waeldrich [mailto:davisamy@example.org]
Sent: Wednesday, September 12, 2007 2:47 AM
To: davisamy@example.org
Subject: RE: EMPTY_DOC thread stability issues

Hi all,

I have checked the proposal of Chris and I really like it. I think the =
best way to proceed is to refactor the XmlUtils class a bit. The =
refatorisation of XmlUtils means that each Thread will have its own =
instance of a document builder. New documents are created by this =
instance. Therefore a new method getDocumentBuilder() is needed. =
Furthermore, the usage of createBuilder() in XmlUtils should be replaced =
by getDocumentBuilder() method. =20

    static final ThreadLocal tls =3D new ThreadLocal(){
        protected Object initialValue() {
           // the method createBuilder needs to be synchronized=20
           return createBuilder();
        }
    };
   =20
    private static DocumentBuilder getDocumentBuilder() {
        return (DocumentBuilder)tls.get();
    }

This also means that the representations of EMPTY_DOC in the Muse code =
can be replaced with createDocument() without experiencing a big =
performance loss. With the changes proposed/done by Vinh I think the =
major parts of the problem should be solved.

Thanks to Chris, Rich and Vinh for the fruitful discussion.

Oliver

-------- Original-Nachricht --------
> Datum: Thu, 6 Sep 2007 17:00:09 +0200
> Von: davisamy@example.org
> An: davisamy@example.org
> Betreff: RE: EMPTY_DOC thread stability issues

> Hi all,
>=20
> @Oliver, I've tried running the tests but I get NPE's from both the=20
> threadlocal version and the current version.  Have I run something=20
> incorrectly?
>=20
> java.lang.NullPointerException
> 	at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source)
> 	at org.apache.xerces.dom.ParentNode.item(Unknown Source)
> 	at
> org.apache.muse.test.thread.local.TestEndpointReference.<init>(TestEnd
> po
> intReference.java:197)
> 	at
> org.apache.muse.test.thread.local.TestThread.run(TestThread.java:60)
> java.lang.NullPointerException
> 	at org.apache.xerces.dom.ParentNode.nodeListItem(Unknown Source)
> 	at org.apache.xerces.dom.ParentNode.item(Unknown Source)
> 	at
> org.apache.muse.test.thread.local.TestEndpointReference.<init>(TestEnd
> po
> intReference.java:197)
> 	at
> org.apache.muse.test.thread.local.TestThread.run(TestThread.java:60)
>=20
> the shared epr and seperate docs versions shows no errors. =20
>=20
> The seperate doc one takes for ever, quite a performance hit on both=20
> the synchronized for getLocalDoc, which shouldn't be necessary since=20
> newInstance is threadsafe on DocumentBuilderFactory and the=20
> createDocument.  I replaced the getLocalDoc with :
>=20
> 	static final ThreadLocal tls =3D new ThreadLocal(){
> 		protected Object initialValue() {
> 			 DocumentBuilderFactory factory =3D
> DocumentBuilderFactory.newInstance();
> 		     factory.setNamespaceAware(true);
> 		     factory.setIgnoringComments(true);
> 		     try
> 		        {
> 		            return factory.newDocumentBuilder();
> 		        }
> 		        catch (ParserConfigurationException error)
> 		        {
> 		            throw new
> RuntimeException(error.getMessage(), error);
> 		        }
> 		}
> 	};
> =09
>     public static Document getLocalDoc() {
>     	return ((DocumentBuilder)tls.get()).newDocument();
> 	}
>=20
> and it improved the performance considerably (equal with the current=20
> solution, but correct).  Creating new documentbuilder factories is=20
> extremly expensive, jar lookups resource creation, class loading etc.
>=20
> cheers,
> Chris
>=20
> PS A drop in replacement of a customised axis 1.4 - does namespaces=20
> etc correctly - runs in 128 secs (half+ the speed of the current buggy =

> impl).  If others are interested this version doesn't suffer threading =

> issues on read only, it just creates a few too many things but it=20
> could be stripped down into a usable general dom.
> PPS I'm going to start working with Vinhs tests now.
>=20
> -----Original Message-----
> From: Vinh Nguyen (vinguye2) [mailto:davisamy@example.org]
> Sent: Thursday, September 06, 2007 3:45 AM
> To: davisamy@example.org
> Subject: RE: EMPTY_DOC thread stability issues
>=20
> My test case has been posted to JIRA Muse-270:
>=20
> https://issues.apache.org/jira/browse/MUSE-270
> =20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: davisamy@example.org
> For additional commands, e-mail: davisamy@example.org

--=20



Psssst! Schon vom neuen GMX MultiMessenger geh=F6rt?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org

---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


From davisamy@example.org Thu Oct 11 14:44:51 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 73326 invoked from network); 11 Oct 2007 14:44:36 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 11 Oct 2007 14:44:36 -0000
Received: (qmail 3089 invoked by uid 500); 11 Oct 2007 14:44:23 -0000
Delivered-To: davisamy@example.org
Received: (qmail 3066 invoked by uid 500); 11 Oct 2007 14:44:23 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 3043 invoked by uid 99); 11 Oct 2007 14:44:23 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2007 07:44:23 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [83.161.120.155] (HELO eero.baz.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Oct 2007 14:44:24 +0000
Received: by eero.baz.org (Postfix, from userid 1017)
	id F3B8D89A19; Thu, 11 Oct 2007 10:43:07 -0400 (EDT)
Received: from [83.161.120.155] (psc.progress.com [83.161.120.155]) by eero
	(tmda-ofmipd) with ESMTP; Thu, 11 Oct 2007 10:43:00 -0400 (EDT)
Message-ID: <davisamy@example.org>
Date: Thu, 11 Oct 2007 10:42:45 -0400
User-Agent: Thunderbird 83.161.120.155 (Windows/20070728)
MIME-Version: 1.0
To: "davisamy@example.org" <davisamy@example.org>
Subject: UPDATE: Board report for October
References: <davisamy@example.org>
In-Reply-To: <davisamy@example.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes)
From: Glen Daniels <davisamy@example.org>
X-Virus-Checked: Checked by ClamAV on apache.org


Hi folks:

Our September board report wasn't in on time due to the PMC chair 
switch, so we're doing it in October.  We have a number of good updates 
in there already, but please take a quick look at the entry for your 
particular project and make sure it's up to date.  I'd like to send this 
in the next couple of days, so please take a moment to do this ASAP.

http://wiki.apache.org/ws/ReportForSep2007

Thanks!

--Glen

-------- Original Message --------
Subject: ASF Board Report for Oct 2007 is now due
Date: 11 Oct 2007 07:50:06 -0000
From: ASF Board <davisamy@example.org>
To: Glen Daniels <davisamy@example.org>



This email was sent by an automated system on behalf of the
ASF Board.

According to board records, you are listed as the chair of at least one
committee that is due to submit a report this month. These reports are
now due and should be submitted to the board as soon as possible.

The meeting is scheduled for Wed, 17 Oct 2007, 10 am PST.

Full details about the process and schedule are in [1].

Your report should be sent in plain-text format to davisamy@example.org
with the word "report" and your project name in the subject.
The content should also be committed to the meeting agenda in the
board directory in the foundation repository.

Thanks,
The ASF Board

[1] - 
https://svn.apache.org/repos/private/committers/board/committee-info.txt


ASF Board Reports
-----------------

Reports are due from you for the following committees:
	 - Web Services


---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


From davisamy@example.org Sun Oct 14 16:19:01 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 85432 invoked from network); 14 Oct 2007 16:19:01 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 14 Oct 2007 16:19:01 -0000
Received: (qmail 5255 invoked by uid 500); 14 Oct 2007 16:18:49 -0000
Delivered-To: davisamy@example.org
Received: (qmail 5231 invoked by uid 500); 14 Oct 2007 16:18:49 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 5220 invoked by uid 99); 14 Oct 2007 16:18:49 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Oct 2007 09:18:49 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of davisamy@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO fk-out-0910.google.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Oct 2007 16:18:52 +0000
Received: by fk-out-0910.google.com with SMTP id f40so1398347fka
        for <davisamy@example.org>; Sun, 14 Oct 2007 09:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
        bh=kvjUVLiHHUmN2ztk+1m2jZM1s2WQMZedTen5nJSbxgo=;
        b=oH9QG5KEix62g1qVrm+PTj6bF3Kjl6iWGXohAPjEjsIGdbPKLsbeH63eXGjTvGTEUJE/1cwjNDbyTlUzQrmVIMpRr9WNcUiXztnPYHKKbAmlDkVvcYM/WfPF0ksqOX6CWTyZkdyYQD4KqXtC9h1sRba4r+7l1mJ+0+GtGcLcPYk=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:mime-version:content-type;
        b=EKarWDpyCYaB5GDWUhOFXgqHd4x1qIcOWbmOXTK1lgIzhu8fXZ0sLewinxSMHn8xWUleuUxgXWNKauzpfmbnAKbCDhR58zDVsxxHgii9HfE5ShcbjqG6VwSYdFsh+nrIfSyqEZmTimqMMNu+kgOqYRHlwem6C8quQcdzblXqcRU=
Received: by 83.161.120.155 with SMTP id z3mr9834595bue.1192378710474;
        Sun, 14 Oct 2007 09:18:30 -0700 (PDT)
Received: by 83.161.120.155 with HTTP; Sun, 14 Oct 2007 09:18:30 -0700 (PDT)
Message-ID: <davisamy@example.org>
Date: Sun, 14 Oct 2007 18:18:30 +0200
From: "Chris Twiner" <davisamy@example.org>
To: davisamy@example.org
Subject: RE: EMPTY_DOC thread stability issues
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_33130_29195533.1192378710473"
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_33130_29195533.1192378710473
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,

Sorry for the slight delay about a patch (on holiday atm).  I've created a
patch and a test case that reproduces the threading issues on a single cpu
machine (based on Vinh's test).  It runs 30 resources each sending 100
messages on startup to a subscriber which simply counts.  The change to
Vinh's test is that there is no tcp connections taking place.  This seems to
be a cause of difficulty for reproducing on a single cpu box (easier for the
scheduler to take care of I assume).

Without the patch it will recieve between 1500 and 2000 messages on my
laptop (probably much less with a >= dual cpu box).  Simply unpack into an
eclipse project run the InlineIsolationLayer main and it will run the test.
The aim is to retrieve all 3000 messages.  I have included a single patched
jar for all of the muse modules, I have not included the 2.2.0 jars as I
expect everyone will already have them.  This should make it easier for
testing.  Needless to say this still requires a large amount of testing on
multi core / smp boxes.

Also included is a file (tsPatch.txt) which is a svn patch against the
branches/2.2.0/trunk.  This includes my proposed tls based solution and also
the getFirstChild()/getNextSibling() solution.  Using the tls
DocumentBuiders alone seems to make the 3000 possible but I suspect it will
not work on other cpus since the getChildren in xerces is non thread safe
(hence the introduction of the NodeChildrenIterator).

Cheers,
Chris

PS (The NodeChildrenIterator doesn't implement Iterator as this requires
casting, and as a one off it made no sense to suffer the impact.  If this is
preferred for stylistic or correctness reasons I'm fine to change it.)

------=_Part_33130_29195533.1192378710473
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,<br><br>Sorry for the slight delay about a patch (on holiday atm).&nbsp; I&#39;ve created a patch and a test case that reproduces the threading issues on a single cpu machine (based on Vinh&#39;s test).&nbsp; It runs 30 resources each sending 100 messages on startup to a subscriber which simply counts.&nbsp; The change to Vinh&#39;s test is that there is no tcp connections taking place.&nbsp; This seems to be a cause of difficulty for reproducing on a single cpu box (easier for the scheduler to take care of I assume).
<br><br>Without the patch it will recieve between 1500 and 2000 messages on my laptop (probably much less with a &gt;= dual cpu box).&nbsp; Simply unpack into an eclipse project run the InlineIsolationLayer main and it will run the test.&nbsp; The aim is to retrieve all 3000 messages.&nbsp; I have included a single patched jar for all of the muse modules, I have not included the 
2.2.0 jars as I expect everyone will already have them.&nbsp; This should make it easier for testing.&nbsp; Needless to say this still requires a large amount of testing on multi core / smp boxes.<br><br>Also included is a file (tsPatch.txt
) which is a svn patch against the branches/2.2.0/trunk.&nbsp; This includes my proposed tls based solution and also the getFirstChild()/getNextSibling() solution.&nbsp; Using the tls DocumentBuiders alone seems to make the 3000 possible but I suspect it will not work on other cpus since the getChildren in xerces is non thread safe (hence the introduction of the NodeChildrenIterator).
<br><br>Cheers,<br>Chris<br><br>PS (The NodeChildrenIterator doesn&#39;t implement Iterator as this requires casting, and as a one off it made no sense to suffer the impact.&nbsp; If this is preferred for stylistic or correctness reasons I&#39;m fine to change it.)
<br>

------=_Part_33130_29195533.1192378710473--

From davisamy@example.org Sun Oct 14 16:26:41 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 86256 invoked from network); 14 Oct 2007 16:26:41 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 14 Oct 2007 16:26:41 -0000
Received: (qmail 8696 invoked by uid 500); 14 Oct 2007 16:26:29 -0000
Delivered-To: davisamy@example.org
Received: (qmail 8675 invoked by uid 500); 14 Oct 2007 16:26:29 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 8664 invoked by uid 99); 14 Oct 2007 16:26:29 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Oct 2007 09:26:29 -0700
X-ASF-Spam-Status: No, hits=-100.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Oct 2007 16:26:41 +0000
Received: from brutus (localhost [83.161.120.155])
	by brutus.apache.org (Postfix) with ESMTP id D204971420E
	for <davisamy@example.org>; Sun, 14 Oct 2007 09:25:50 -0700 (PDT)
Message-ID: <33071846.1192379150857.JavaMail.jira@brutus>
Date: Sun, 14 Oct 2007 09:25:50 -0700 (PDT)
From: "Chris Twiner (JIRA)" <davisamy@example.org>
To: davisamy@example.org
Subject: [jira] Updated: (MUSE-270) EMPTY_DOC thread stability issues
In-Reply-To: <8435282.1188919126090.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org


     [ https://issues.apache.org/jira/browse/MUSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Twiner updated MUSE-270:
------------------------------

    Attachment: MuseThreadSafety.zip

Attached simplified test for single cpus.  Also included is a patch from the 2.2.0 branch.  Is it possible that, if this patch is accepted, that this could be made a version 2.2.1 instead of in 2.3?

> EMPTY_DOC thread stability issues
> ---------------------------------
>
>                 Key: MUSE-270
>                 URL: https://issues.apache.org/jira/browse/MUSE-270
>             Project: Muse
>          Issue Type: Bug
>          Components: Utilities - General, QName, and XML, WS-Addressing and SOAP
>    Affects Versions: 2.0.0 M1, 2.0.0 M2, 2.0.0, 2.1.0, 2.2.0, 2.3.0
>         Environment: Impacts all platforms and configurations
>            Reporter: Rich Lucente
>            Assignee: Dan Jemiolo
>             Fix For: 2.3.0
>
>         Attachments: epr-tests.zip, MuseThreadSafety.zip, WsnErrorsTest.zip
>
>
> This bug is being opened to track the EMPTY_DOC thread stability issue currently being discussed on the muse-dev mailing list.  XmlUtils provides EMPTY_DOC as a scratchpad instance of a DOM Document for creation of elements.  This has been shown to cause exceptions in a multi-threaded environment.  The issue is compounded by the widespread use of EMPTY_DOC in the code due to its convenience and the reduction in object creation when constructing XML fragments.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


From davisamy@example.org Sun Oct 14 22:39:27 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 66225 invoked from network); 14 Oct 2007 22:39:27 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 14 Oct 2007 22:39:27 -0000
Received: (qmail 1880 invoked by uid 500); 14 Oct 2007 22:39:15 -0000
Delivered-To: davisamy@example.org
Received: (qmail 1867 invoked by uid 500); 14 Oct 2007 22:39:15 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 1855 invoked by uid 99); 14 Oct 2007 22:39:15 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Oct 2007 15:39:15 -0700
X-ASF-Spam-Status: No, hits=-4.0 required=10.0
	tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of davisamy@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO e23smtp03.au.ibm.com) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Oct 2007 22:39:16 +0000
Received: from sd0109e.au.ibm.com (d23rh905.au.ibm.com [83.161.120.155])
	by e23smtp03.au.ibm.com (8.13.1/8.13.1) with ESMTP id l9EMWZBr015947
	for <davisamy@example.org>; Mon, 15 Oct 2007 08:32:35 +1000
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [83.161.120.155])
	by sd0109e.au.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l9EMaAvH289690
	for <davisamy@example.org>; Mon, 15 Oct 2007 08:36:10 +1000
Received: from d23av03.au.ibm.com (loopback [83.161.120.155])
	by d23av03.au.ibm.com (83.161.120.15560308/8.13.3) with ESMTP id l9EMWKXG016279
	for <davisamy@example.org>; Mon, 15 Oct 2007 08:32:20 +1000
X-Authentication-Warning: d23av03.au.ibm.com: Processed from queue /var/spool/mqueue/active*
X-Authentication-Warning: d23av03.au.ibm.com: Processed by postman with -C /relay/etc/sendmail.cf-deliver
Received: from d23ml063.in.ibm.com (d23ml063.in.ibm.com [83.161.120.155])
	by d23av03.au.ibm.com (83.161.120.15560308/8.12.11) with ESMTP id l9EMWJlS016040
	for <davisamy@example.org>; Mon, 15 Oct 2007 08:32:20 +1000
Subject: Saurabh Dravid is out of the office.
From: Saurabh Dravid <davisamy@example.org>
To: davisamy@example.org
Message-ID: <davisamy@example.org>
Date: Mon, 15 Oct 2007 04:02:47 +0530
X-MIMETrack: Serialize by Router on d23ml063/23/M/IBM(Release 7.0.2HF32 | October 17, 2006) at
 15/10/2007 04:02:57
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Virus-Checked: Checked by ClamAV on apache.org


I will be out of the office starting  12/10/2007 and will not return until
22/10/2007.

Thanks for your email. I will be back to work only on 22-Oct-2007 and will
respond once I return. For any urgent issues contact my manager "M R
Ananda" (davisamy@example.org).


---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


From davisamy@example.org Mon Oct 15 15:24:46 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 19180 invoked from network); 15 Oct 2007 15:24:45 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 15 Oct 2007 15:24:45 -0000
Received: (qmail 4073 invoked by uid 500); 15 Oct 2007 15:24:32 -0000
Delivered-To: davisamy@example.org
Received: (qmail 4054 invoked by uid 500); 15 Oct 2007 15:24:32 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 4027 invoked by uid 99); 15 Oct 2007 15:24:32 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Oct 2007 08:24:32 -0700
X-ASF-Spam-Status: No, hits=-100.0 required=10.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Oct 2007 15:24:44 +0000
Received: from brutus (localhost [83.161.120.155])
	by brutus.apache.org (Postfix) with ESMTP id 0270F7141EB
	for <davisamy@example.org>; Mon, 15 Oct 2007 08:23:54 -0700 (PDT)
Message-ID: <24524582.1192461833983.JavaMail.jira@brutus>
Date: Mon, 15 Oct 2007 08:23:53 -0700 (PDT)
From: "Chris Twiner (JIRA)" <davisamy@example.org>
To: davisamy@example.org
Subject: [jira] Created: (MUSE-274) Abstract thread and timer handling,
 allow custom threading and improved scalability
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Abstract thread and timer handling, allow custom threading and improved scalability
-----------------------------------------------------------------------------------

                 Key: MUSE-274
                 URL: https://issues.apache.org/jira/browse/MUSE-274
             Project: Muse
          Issue Type: Improvement
          Components: Other
    Affects Versions: 2.2.0
         Environment: J2EE is especially appropriate for removing Thread's.  JCA spec can be used as an implementation for example.
            Reporter: Chris Twiner
            Assignee: Dan Jemiolo


Currently Muse has many seperate locations where Threads are created.  This does not work well in either a managed environment or from a scalability perspective.  Ideally the default implementation would use a thread pool, and a J2EE impl could use JCA or commonj impls.

Issue -> Environment should have a "getWorkManager" function which allows running of runables from the code that would normally use a thread.  The actual  implementation should be configurable in muse.xml.  This would allow implementations to vary depending on requirements.

The interfaces should aim to cover the existing (and the forthcoming discovery) functionality but not much more  (i.e. provide cancelation of timertasks and simple interval based scheduling).

It is possible to subclass the base capabilities to use different threading models but the use of private's everywhere makes this more problematic.  Providing a pluggable interface would ease integrations.

As an aside, I'm willing to work on this if people think its a good idea.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org


From davisamy@example.org Wed Oct 17 19:37:05 2007
Return-Path: <davisamy@example.org>
Delivered-To: davisamy@example.org
Received: (qmail 65117 invoked from network); 17 Oct 2007 19:37:05 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155)
  by minotaur.apache.org with SMTP; 17 Oct 2007 19:37:05 -0000
Received: (qmail 43101 invoked by uid 500); 17 Oct 2007 19:23:50 -0000
Delivered-To: davisamy@example.org
Received: (qmail 43083 invoked by uid 500); 17 Oct 2007 19:23:49 -0000
Mailing-List: contact davisamy@example.org; run by ezmlm
Precedence: bulk
list-help: <mailto:davisamy@example.org>
list-unsubscribe: <mailto:davisamy@example.org>
List-Post: <mailto:davisamy@example.org>
Reply-To: davisamy@example.org
List-Id: <muse-dev.ws.apache.org>
Delivered-To: mailing list davisamy@example.org
Received: (qmail 43068 invoked by uid 99); 17 Oct 2007 19:23:49 -0000
Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Oct 2007 12:23:49 -0700
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=SPF_PASS,URIBL_BLACK,WHOIS_NETSOLPR
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of davisamy@example.org designates 83.161.120.155 as permitted sender)
Received: from [83.161.120.155] (HELO mail.gmx.net) (83.161.120.155)
    by apache.org (qpsmtpd/0.29) with SMTP; Wed, 17 Oct 2007 19:23:50 +0000
Received: (qmail 6641 invoked by uid 0); 17 Oct 2007 19:23:28 -0000
Received: from 83.161.120.155 by www097.gmx.net with HTTP;
 Wed, 17 Oct 2007 21:23:28 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 17 Oct 2007 21:23:28 +0200
From: "Oliver Waeldrich" <davisamy@example.org>
In-Reply-To: <davisamy@example.org>
Message-ID: <davisamy@example.org>
MIME-Version: 1.0
References: <davisamy@example.org>
Subject: stripping of namespace problem in muse
To: davisamy@example.org
X-Authenticated: #19259262
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1+mgUsUzx6mzSvfRrSfq09fIXd5H640l/G5OFx7O7
 0czoRCheSDF45yfoHJtpYAFGP+qVcGnx676g== 
Content-Transfer-Encoding: 8bit
X-GMX-UID: CFMvcu9neWUoSRa+VnRz3g4xU3U4N8/d
X-Virus-Checked: Checked by ClamAV on apache.org

Dear all,

In the createElement() method of XmlUtils by default all xmlns namespaces declarations are striped off. In MUSE-232 this issue was partially addressed in order to support fully qualified attributes. However, it turned out that this patch addresses this issue only partially. The following XML snippet illustrates the problem:

<myelement xmlns:tns="http://foo.org" xsi:type="tns:bar">1234<myelement>

Here, the xmlns attribute is stripped off, which results in an error in later deserialisation. The reason why these attributes are stripped off is according to a code comment a bug in Xerces. However, I was not able to reproduce the bug mentioned, nor is there a concrete reference. Could somebody give me a hint why this "hack" was actually introduced in the code (Dan, do you know sonething about it?). This might help to find a better solution than the current one. Furthermore, since MUSE-225 potentially addressed a related issue, this Xerces hack might be obsolete. 

Thanks a lot,
Oliver
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

---------------------------------------------------------------------
To unsubscribe, e-mail: davisamy@example.org
For additional commands, e-mail: davisamy@example.org



{'source': 'Apache Software Foundation Public Mail Archives'}