Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 14867 invoked from network); 19 Jul 2006 00:59:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Jul 2006 00:59:09 -0000 Received: (qmail 97161 invoked by uid 500); 19 Jul 2006 00:59:08 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 97126 invoked by uid 500); 19 Jul 2006 00:59:08 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 97117 invoked by uid 99); 19 Jul 2006 00:59:08 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jul 2006 17:59:08 -0700 X-ASF-Spam-Status: No, hits=1.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [32.97.182.142] (HELO e2.ny.us.ibm.com) (32.97.182.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Jul 2006 17:59:06 -0700 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6J0witd000685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 18 Jul 2006 20:58:45 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k6J0wi6G287764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Jul 2006 20:58:45 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k6J0wi4N017492 for ; Tue, 18 Jul 2006 20:58:44 -0400 Received: from [9.76.197.45] (sig-9-76-197-45.mts.ibm.com [9.76.197.45]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k6J0whYm017469 for ; Tue, 18 Jul 2006 20:58:44 -0400 Message-ID: <44BD83BF.1000806@sbcglobal.net> Date: Tue, 18 Jul 2006 17:58:39 -0700 From: Kathey Marsden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: DDMWriter - MAX_MARKS_NESTING - Is 10 high enough? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I am working on an issue where the following exception occured after a long 16hr stress run. I don't have enough to file a bug yet and don't have line numbers but thought I would throw this out there as a start. Looking at the code I see think it might be related to MAX_MARKS_NESTING. Looking at EXCSQLSTT it seems it could have up to 20 optional or required parameters. I don't know that Network Server will ever seend that many. I am collecting more information and trying to get a reproducible case, but I was curious about MAX_MARKS_NESTING and if it needs to be larger than 10. Here is the information: THE TRACE after 16 hour run java.lang.ArrayIndexOutOfBoundsException at org.apache.derby.impl.drda.DDMWriter.startDdm(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARD(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARDs(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.writeSQLCARDs(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.checkWarning(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT(Unknown Source) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source)M COMMENT FOR MAX_MARKS_NESTING in DDMWriter // number of nesting levels for collections. We need to mark the length // location of the collection so that we can update it as we add more stuff // to the collection private final static int MAX_MARKS_NESTING = 10; CODE FOR startDdm And the code for startDdm. I suspect top has exceeded 10. I suppose it could be offset for bytes, but the ensurelength(4) seems like it should take care of that. protected void startDdm (int codePoint) { // save the location of the beginning of the collection so // that we can come back and fill in the length bytes markStack[top++] = offset; ensureLength (4); // verify space for length bytes and code point offset += 2; // move past the length bytes before writing the code point bytes[offset] = (byte) ((codePoint >>> 8) & 0xff); bytes[offset + 1] = (byte) (codePoint & 0xff); offset += 2; }