From derby-user-return-14072-apmail-db-derby-user-archive=db.apache.org@db.apache.org Sun Dec 11 21:15:51 2011 Return-Path: X-Original-To: apmail-db-derby-user-archive@www.apache.org Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 53A1F7A97 for ; Sun, 11 Dec 2011 21:15:51 +0000 (UTC) Received: (qmail 78499 invoked by uid 500); 11 Dec 2011 21:15:51 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 78470 invoked by uid 500); 11 Dec 2011 21:15:51 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 78463 invoked by uid 99); 11 Dec 2011 21:15:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Dec 2011 21:15:50 +0000 X-ASF-Spam-Status: No, hits=-0.1 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [141.146.126.227] (HELO acsinet15.oracle.com) (141.146.126.227) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 11 Dec 2011 21:15:39 +0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBBLFHoD012655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 11 Dec 2011 21:15:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBBLFH85013750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 Dec 2011 21:15:17 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBBLFBH8030863 for ; Sun, 11 Dec 2011 15:15:11 -0600 Received: from [192.168.103.18] (/91.186.78.215) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 11 Dec 2011 13:15:11 -0800 Message-ID: <4EE51D8F.1040803@oracle.com> Date: Sun, 11 Dec 2011 22:15:59 +0100 From: Kristian Waagan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: derby-user@db.apache.org Subject: Re: SQLChar.getCollationKey NPE in index-stat-thread References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020903090801090105060106" X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4EE51D66.0053,ss=1,re=-2.300,fgs=0 X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------020903090801090105060106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11.12.2011 19:42, Jean-Yves Linet wrote: > Hi, > I am upgrading Derby to last version 10.8.2.2 and I am stopped by what > seams to be a bug. > > After activation ot stats trace I get this : > > Sun Dec 11 19:33:11 CET 2011 Thread[pool-3-thread-1,5,main] {istat} > "PROXIFLEX"."IDAXX_RES": update scheduled, reason=[no stats, > row-estimate=375] (queueSize=1) > Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] > {istat,trace@26130360} worker thread started (xid=12049) > [q/p/s=1/0/1,err:k/u/c=0/0/0,rej:f/d/o=0/0/0] > Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] > {istat,trace@26130360} processing "PROXIFLEX"."IDAXX_RES" > Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] {istat} > runtime exception during normal operation > java.lang.NullPointerException > at org.apache.derby.iapi.types.SQLChar.getCollationKey(Unknown Source) > at > org.apache.derby.iapi.types.WorkHorseForCollatorDatatypes.stringCompare(Unknown > Source) > at > org.apache.derby.iapi.types.CollatorSQLVarchar.stringCompare(Unknown > Source) > at org.apache.derby.iapi.types.SQLChar.compare(Unknown Source) > at > org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl$KeyComparator.compareWithPrevKey(Unknown > Source) > at > org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.updateIndexStatsMinion(Unknown > Source) > at > org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.generateStatistics(Unknown > Source) > at > org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.processingLoop(Unknown > Source) > at > org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.run(Unknown > Source) > at java.lang.Thread.run(Thread.java:662) > Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] > {istat,trace@26130360} worker thread exit > [q/p/s=0/0/1,err:k/u/c=0/0/0,rej:f/d/o=0/0/0] > > My JDBC connection url is > : jdbc:derby:directory:db_name;territory=fr_FR;collation=TERRITORY_BASED:PRIMARY;create=true > > If I remove territory and collation parameters I don't have the exception. > > I didn't find bug report for this. > Should I make a JIRA entry or does a workaround exists ? Hi Jean-Yves, Yes, please create a JIRA issue to track this bug. > > I also found undocumented property to disable the automatic statistics > (derby.storage.indexStats.auto). > Can I set this property to false until the problem is solved without > any side effect ? Yes, you can disable the automatic statistics. This will basically make Derby 10.8 behave as older versions wrt index cardinality statistics. If you see performance drops on queries which involves tables that grow/shrink a lot, you should consider updating the statistics manually. I believe work is in progress to document the istat feature properly. We're still looking for feedback from people on whether the feature is working satisfactory or not - in your case it obviously isn't due to what appears to be a bug related to collations. Regards, -- Kristian > > Thanks > > -- > Jean-Yves LINET --------------020903090801090105060106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11.12.2011 19:42, Jean-Yves Linet wrote:
Hi,
I am upgrading Derby to last version 10.8.2.2 and I am stopped by what seams to be a bug.

After activation ot stats trace I get this :

Sun Dec 11 19:33:11 CET 2011 Thread[pool-3-thread-1,5,main] {istat} "PROXIFLEX"."IDAXX_RES": update scheduled, reason=[no stats, row-estimate=375] (queueSize=1)
Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] {istat,trace@26130360} worker thread started (xid=12049) [q/p/s=1/0/1,err:k/u/c=0/0/0,rej:f/d/o=0/0/0]
Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] {istat,trace@26130360}     processing "PROXIFLEX"."IDAXX_RES" 
Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] {istat} runtime exception during normal operation
java.lang.NullPointerException
at org.apache.derby.iapi.types.SQLChar.getCollationKey(Unknown Source)
at org.apache.derby.iapi.types.WorkHorseForCollatorDatatypes.stringCompare(Unknown Source)
at org.apache.derby.iapi.types.CollatorSQLVarchar.stringCompare(Unknown Source)
at org.apache.derby.iapi.types.SQLChar.compare(Unknown Source)
at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl$KeyComparator.compareWithPrevKey(Unknown Source)
at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.updateIndexStatsMinion(Unknown Source)
at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.generateStatistics(Unknown Source)
at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.processingLoop(Unknown Source)
at org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.run(Unknown Source)
at java.lang.Thread.run(Thread.java:662)
Sun Dec 11 19:33:11 CET 2011 Thread[index-stat-thread,5,main] {istat,trace@26130360} worker thread exit [q/p/s=0/0/1,err:k/u/c=0/0/0,rej:f/d/o=0/0/0]

My JDBC connection url is : jdbc:derby:directory:db_name;territory=fr_FR;collation=TERRITORY_BASED:PRIMARY;create=true

If I remove territory and collation parameters I don't have the exception.

I didn't find bug report for this.
Should I make a JIRA entry or does a workaround exists ?

Hi Jean-Yves,

Yes, please create a JIRA issue to track this bug.


I also found undocumented property to disable the automatic statistics (derby.storage.indexStats.auto).
Can I set this property to false until the problem is solved without any side effect ?

Yes, you can disable the automatic statistics. This will basically make Derby 10.8 behave as older versions wrt index cardinality statistics. If you see performance drops on queries which involves tables that grow/shrink a lot, you should consider updating the statistics manually.
I believe work is in progress to document the istat feature properly. We're still looking for feedback from people on whether the feature is working satisfactory or not - in your case it obviously isn't due to what appears to be a bug related to collations.


Regards,
--
Kristian


Thanks

--
Jean-Yves LINET

--------------020903090801090105060106--