[jira] [Comment Edited] (DERBY-6856) Make it possible to build Derby using JDK 9
[ https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966236#comment-15966236 ] Kathey Marsden edited comment on DERBY-6856 at 4/12/17 5:18 PM: I just wanted to say thank you Rick for this and past work with the new JDK's. Early testing and verification for Derby has been great for both for Derby and for the JDK's being tested to pop bugs and compatibility issues early. Also it keeps Derby running and relevant under the new JDK's. Myrna has done a lot of this too work in the past too and both endeavors have made a big difference in quality all around. Thank you! was (Author: kmarsden): I just wanted to say thank you Rick for this and past work with the new JDK's. Early testing and verification for Derby has been great for both for Derby and for the JDK's being tested to pop bugs and compatibility issues early. Myrna has done a lot of this too work in the past too and both endeavors have made a big difference in quality all around. Thank you! > Make it possible to build Derby using JDK 9 > --- > > Key: DERBY-6856 > URL: https://issues.apache.org/jira/browse/DERBY-6856 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas > Attachments: derby-6856-01-ab-addShardingKey.diff, > derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff, > derby-6856-03-aa-autoboxingDeprecationWarnings.diff, > derby-6856-03-ab-autoboxingDeprecationWarnings.diff, > derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff, > derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff, > derby-6856-05-ac-roundingMode-Class.newInstance.diff, > derby-6856-05-af-roundingMode-Class.getDeclaredConstructor.diff, > derby-6856-05-ag-roundingMode-Class.newInstance.diff, > derby-6856-06-aa-observable.diff, derby-6856-07-aa-oneMoreNewInstance.diff, > derby-6856-08-aa-cleanupJavadoc.diff, derby-6856-09-aa-javadocEntities.diff, > derby-6856-10-aa-disable-permissions-subverting-test.diff, > derby-6856-11-aa-jigsawResourceLocation.diff, derby-6856-XX-ab-base.diff, > derby-6856-XX-ac-base.diff, derby-6856-XX-ad-base.diff, > derby-6856-XX-ae-base.diff, PTest.java, ptestScript > > > Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like > java.sql.ShardingKey and methods which refer to these new classes. > In addition, project Jigsaw has created a new way to name classes (see > http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool > which we use so that old JVMs can compile Derby and so that Derby can be > compiled to run on old JVMs. > It is likely that we will need to leave this issue open throughout the > development cycle of Java 9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9
[ https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15966236#comment-15966236 ] Kathey Marsden commented on DERBY-6856: --- I just wanted to say thank you Rick for this and past work with the new JDK's. Early testing and verification for Derby has been great for both for Derby and for the JDK's being tested to pop bugs and compatibility issues early. Myrna has done a lot of this too work in the past too and both endeavors have made a big difference in quality all around. Thank you! > Make it possible to build Derby using JDK 9 > --- > > Key: DERBY-6856 > URL: https://issues.apache.org/jira/browse/DERBY-6856 > Project: Derby > Issue Type: Improvement > Components: Build tools >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas > Attachments: derby-6856-01-ab-addShardingKey.diff, > derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff, > derby-6856-03-aa-autoboxingDeprecationWarnings.diff, > derby-6856-03-ab-autoboxingDeprecationWarnings.diff, > derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff, > derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff, > derby-6856-05-ac-roundingMode-Class.newInstance.diff, > derby-6856-05-af-roundingMode-Class.getDeclaredConstructor.diff, > derby-6856-05-ag-roundingMode-Class.newInstance.diff, > derby-6856-06-aa-observable.diff, derby-6856-07-aa-oneMoreNewInstance.diff, > derby-6856-08-aa-cleanupJavadoc.diff, derby-6856-09-aa-javadocEntities.diff, > derby-6856-10-aa-disable-permissions-subverting-test.diff, > derby-6856-11-aa-jigsawResourceLocation.diff, derby-6856-XX-ab-base.diff, > derby-6856-XX-ac-base.diff, derby-6856-XX-ad-base.diff, > derby-6856-XX-ae-base.diff, PTest.java, ptestScript > > > Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like > java.sql.ShardingKey and methods which refer to these new classes. > In addition, project Jigsaw has created a new way to name classes (see > http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool > which we use so that old JVMs can compile Derby and so that Derby can be > compiled to run on old JVMs. > It is likely that we will need to leave this issue open throughout the > development cycle of Java 9. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6921) How good is the Derby Query Optimizer, really
[ https://issues.apache.org/jira/browse/DERBY-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942083#comment-15942083 ] Kathey Marsden commented on DERBY-6921: --- Hi Harshvardhan, I think only the official mentors can access the proposals submitted through google. If you could put it in a location where everyone can see it, that would be great. In the past Students have used the Derby Wiki for this purpose, for example Tiago, who I think is going to be back helping mentor this year. https://wiki.apache.org/db-derby/Tiago_Espinha > How good is the Derby Query Optimizer, really > - > > Key: DERBY-6921 > URL: https://issues.apache.org/jira/browse/DERBY-6921 > Project: Derby > Issue Type: Improvement > Components: SQL >Reporter: Bryan Pendleton >Priority: Minor > Labels: database, gsoc2017, java, optimizer > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > At the 2015 VLDB conference, a team led by Dr. Viktor Leis at Munich > Technical University introduced a new benchmark suite for evaluating > database query optimizers: http://www.vldb.org/pvldb/vol9/p204-leis.pdf > The benchmark test suite is publically available: > http://db.in.tum.de/people/sites/leis/qo/job.tgz > The data set for running the benchmark is publically available: > ftp://ftp.fu-berlin.de/pub/misc/movies/database/ > As part of Google Summer of Code 2017, I am volunteering to mentor > a Summer of Code intern who is interested in using these tools to > improve the Derby query optimizer. > My suggestion for the overall process is this: > 1) Acquire the benchmark tools, and the data set > 2) Run the benchmark. > 2a) Some of the benchmark queries may reveal bugs in Derby. > For each such bug, we need to isolate the bug and fix it. > 3) Once we are able to run the entire benchmark, we need to >analyze the results. > 3a) Some of the benchmark queries may reveal opportunities >for Derby to improve the query plans that it chooses for >various classes of queries (this is explained in detail in the >VLDB paper and other information available at Dr. Leis's site) >For each such improvement, we need to isolate the issue, >report it as a separable improvement, and fix it (if we can) > While the benchmark is an interesting exercise in and of itself, > the overall goal of the project is to find-and-fix problems in the > Derby query optimizer, specifically in the 3 areas which are > the focus of the benchmark tool: > 1) How good is the Derby cardinality estimator and when does >it lead to slow queries? > 2) How good it the Derby cost model, and how well is it guiding >the overall query optimization process? > 3) How large is the Derby enumerated plan space, and is it >appropriately-sized? > While other Derby issues have been filed against these questions > in the past, the intent of this specific project is to use the concrete > tools provided by the VLDB paper to make this effort rigorous and > successful at making concrete improvements to the Derby query > optimizer. > If you are interested in pursuing this project, please take these > considerations into mind: > 1) This is NOT an introductory project. You must be quite familiar >with DBMS systems, and with SQL, and in particular with >cost-based query optimization. If terms such as "cardinality >estimation", "correlated query predicates", or "bushy trees" >aren't comfortable terms for you ,this probably isn't the >project you're interested in. > 2) If you are new to Derby, that is fine, but please take advantage >of the extensive body of introductory material on Derby to >become familiar with it: read the Derby Getting Started manual, >download the software and follow the tutorials, read the documentation, >download the source code and learn how to build and run the >test suites, etc. > 3) All I have presented here is an **outline** of the project. You will >need to read the paper(s), study the benchmark queries, and >propose a detailed plan for how to use this benchmark as a tool >for improving the Derby query optimizer. > If these sorts of tasks sound like exciting things to do, then please > let us know! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (DERBY-6929) NPE in EmbeddedDriver on Apache Tomcat hosted on Ubuntu 15
[
https://issues.apache.org/jira/browse/DERBY-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15941753#comment-15941753
]
Kathey Marsden commented on DERBY-6929:
---
Does Tomcat have the ability to specify a separate class loader for the
conflicting applications?
> NPE in EmbeddedDriver on Apache Tomcat hosted on Ubuntu 15
> --
>
> Key: DERBY-6929
> URL: https://issues.apache.org/jira/browse/DERBY-6929
> Project: Derby
> Issue Type: Bug
> Components: JDBC
>Affects Versions: 10.12.1.1
>Reporter: J P
>Priority: Blocker
> Attachments: derby.log
>
>
> Apache Tomcat 8.0.14
> Jackrabbit 2.1.2.1
> Derby 10.12.1.1
> All was working fine and all of a sudden it starts failing with below trace.
> {code}
> 23-Mar-2017 13:54:01.173 INFO [main]
> org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
> Engine: Apache Tomcat/8.0.14 (Ubuntu)
> 23-Mar-2017 13:54:01.209 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deploying
> configuration descriptor /etc/tomcat8/Catalina/localhost/manager.xml
> 23-Mar-2017 13:54:02.418 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 23-Mar-2017 13:54:02.477 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
> configuration descriptor /etc/tomcat8/Catalina/localhost/manager.xml has
> finished in 1,266 ms
> 23-Mar-2017 13:54:02.478 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deploying
> configuration descriptor /etc/tomcat8/Catalina/localhost/host-manager.xml
> 23-Mar-2017 13:54:02.919 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 23-Mar-2017 13:54:02.925 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
> configuration descriptor /etc/tomcat8/Catalina/localhost/host-manager.xml has
> finished in 447 ms
> 23-Mar-2017 13:54:02.925 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deploying
> configuration descriptor /etc/tomcat8/Catalina/localhost/Jarma.xml
> 23-Mar-2017 13:54:56.413 SEVERE [localhost-startStop-1]
> org.apache.catalina.core.ContainerBase.addChildInternal
> ContainerBase.addChild: start:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/Jarma]]
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:724)
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700)
> at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:581)
> at
> org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1685)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'studentEngine': Injection of autowired dependencies
> failed; nested exception is
> org.springframework.beans.factory.BeanCreationException: Could not autowire
> field: com.nestincubate.jw.services.StudentService
> com.nestincubate.engine.StudentEngine.studentService; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating bean
> with name 'studentService': Injection of autowired dependencies failed;
> nested exception is org.springframework.beans.factory.BeanCreationException:
> Could not autowire field: com.nestincubate.jw.services.InstitutionTestService
> com.nestincubate.jw.services.StudentService.institutionTestService; nested
> exception is org.springframework.beans.factory.BeanCreationException: Error
>
[jira] [Commented] (DERBY-5936) AllocPage.ReadContainerInfo throws ArrayIndexOutOfBoundsException at arraycopy
[
https://issues.apache.org/jira/browse/DERBY-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15930131#comment-15930131
]
Kathey Marsden commented on DERBY-5936:
---
Petr, what java version are you using? What is the output that you see in the
.dat? If you can't show us the .dat contents, is it output that your
application produced or output that you think was produced by Derby? I seem to
have some vague recollection of a very old java bug like this. I will search
Jira and the archives and see if I can find something to jog my memory.
> AllocPage.ReadContainerInfo throws ArrayIndexOutOfBoundsException at arraycopy
> --
>
> Key: DERBY-5936
> URL: https://issues.apache.org/jira/browse/DERBY-5936
> Project: Derby
> Issue Type: Bug
> Components: Store
>Affects Versions: 10.6.1.0
> Environment: intel, windows XP, embedded driver, c3p0
>Reporter: Yuan Yao
> Labels: derby_triage10_12
>
> The db may not be closed normally. It throws following exceptions as starting.
> logs:
> {code}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.derby.impl.store.raw.data.AllocPage.ReadContainerInfo(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.FileContainer.readHeader(Unknown Source)
> at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(Unknown
> Source)
> at org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown Source)
> at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openDroppedContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.xact.Xact.openDroppedContainer(Unknown Source)
> at
> org.apache.derby.impl.store.raw.data.ContainerBasicOperation.findContainer(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.ContainerBasicOperation.needsRedo(Unknown
> Source)
> at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
> at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
> at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown
> Source)
> at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown
> Source)
> at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
> at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown
> Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown
> Source)
> ... 24 more
> {code}
> I'd like to upload data files if necessary.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (DERBY-4091) Investigate "size_problem" column in MailJdbc terst
[ https://issues.apache.org/jira/browse/DERBY-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15201353#comment-15201353 ] Kathey Marsden commented on DERBY-4091: --- Sorry for the late reply on this. I looked back at the ancient bug database that was used before contribution and don't see anything that is relevant. From the name, one thing you might want to look at is the database growth over time and see if it is different than with the column in. Database growth was the symptom with DERBY-4152, now fixed. > Investigate "size_problem" column in MailJdbc terst > --- > > Key: DERBY-4091 > URL: https://issues.apache.org/jira/browse/DERBY-4091 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden >Priority: Minor > Attachments: Activity.out, DERBY-4091-2.diff > > > In the MailJdbc test there is a table > CREATE TABLE inbox (id bigint generated always as identity (start with > 1,increment by 1), > from_name varchar(64), > to_name varchar(64), > message clob(3M), > date timestamp, > folder_id Integer, > to_delete smallint default 0, > exp_date timestamp, > attach_id smallint default 0, > size_problem varchar(32672), > CONSTRAINT inbox__pk PRIMARY KEY (id)); > > Which has a column "size_problem". We always insert into this column the value > insertFirst > .setString( > 6, > "This column is > used only to by pass the space problem. If the problem still exists, then we > are going to " > > + "have a serious issue > here.*"); > Which seems to imply there is some bug that manifests itself if we don't > have this column, but I don't see a bug reference. It would be interesting > to take the column out and see what happens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4091) Investigate "size_problem" column in MailJdbc terst
[ https://issues.apache.org/jira/browse/DERBY-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15202493#comment-15202493 ] Kathey Marsden commented on DERBY-4091: --- Excellent. Thanks Bryan for checking. > Investigate "size_problem" column in MailJdbc terst > --- > > Key: DERBY-4091 > URL: https://issues.apache.org/jira/browse/DERBY-4091 > Project: Derby > Issue Type: Task > Components: Test >Affects Versions: 10.5.1.1 >Reporter: Kathey Marsden >Assignee: Sandeep Samdaria >Priority: Minor > Attachments: Activity.out, DERBY-4091-2.diff > > > In the MailJdbc test there is a table > CREATE TABLE inbox (id bigint generated always as identity (start with > 1,increment by 1), > from_name varchar(64), > to_name varchar(64), > message clob(3M), > date timestamp, > folder_id Integer, > to_delete smallint default 0, > exp_date timestamp, > attach_id smallint default 0, > size_problem varchar(32672), > CONSTRAINT inbox__pk PRIMARY KEY (id)); > > Which has a column "size_problem". We always insert into this column the value > insertFirst > .setString( > 6, > "This column is > used only to by pass the space problem. If the problem still exists, then we > are going to " > > + "have a serious issue > here.*"); > Which seems to imply there is some bug that manifests itself if we don't > have this column, but I don't see a bug reference. It would be interesting > to take the column out and see what happens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-6841) Derby v10.12.1.1 is horribly slow compared to v10.11.1.1 in embedded mode
[ https://issues.apache.org/jira/browse/DERBY-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-6841. --- Resolution: Not A Problem Resolving as not a problem as the performance difference was due to comparing a connection that required soft upgrade with one that did not. It might be worth while to file an enhancement request to improve the performance of connections to a soft upgraded database. > Derby v10.12.1.1 is horribly slow compared to v10.11.1.1 in embedded mode > - > > Key: DERBY-6841 > URL: https://issues.apache.org/jira/browse/DERBY-6841 > Project: Derby > Issue Type: Bug > Components: JDBC, SQL >Affects Versions: 10.12.1.1 > Environment: OS: Windows, OS X, Linux > CPU: Quad-Core Intel i5 > App: Swing, multi-threaded >Reporter: Xavion > Fix For: 10.11.1.1 > > Attachments: 10.11.1.1.txt, 10.12.1.1-Fresh.txt, 10.12.1.1-Hard.txt, > 10.12.1.1-Soft.txt, DERBY_6841.java > > > It takes much longer to open, read, and close embedded databases using > v10.12.1.1 than it did with v10.11.1.1. What ever changes you guys made over > the last year and a bit have definitely been for the worse. > Below are the results of the repetition tests I've just run on the same > computer with the same databases. Let me know if you need to know about the > sizes of the databases and/or the file type they contain. > Connecting with v10.11.1.1: > Database opened in 0.82 seconds. > Database opened in 0.77 seconds. > Database opened in 0.88 seconds. > Database opened in 0.77 seconds. > Database opened in 0.77 seconds. > Database opened in 0.96 seconds. > Database opened in 0.74 seconds. > Connecting with v10.12.1.1: > Database opened in 1.98 seconds. > Database opened in 2.07 seconds. > Database opened in 1.97 seconds. > Database opened in 2.01 seconds. > Database opened in 2.01 seconds. > Database opened in 2.00 seconds. > Database opened in 2.03 seconds. > Reading with v10.11.1.1: > Database processed in 6.17 seconds. > Database processed in 4.00 seconds. > Database processed in 3.67 seconds. > Database processed in 3.66 seconds. > Database processed in 3.78 seconds. > Database processed in 3.69 seconds. > Database processed in 3.74 seconds. > Reading with v10.12.1.1: > Database processed in 7.29 seconds. > Database processed in 4.54 seconds. > Database processed in 4.88 seconds. > Database processed in 4.65 seconds. > Database processed in 4.34 seconds. > Database processed in 4.35 seconds. > Database processed in 4.50 seconds. > Disconnecting with v10.11.1.1: > Database closed in 0.11 seconds. > Database closed in 0.13 seconds. > Database closed in 0.15 seconds. > Database closed in 0.14 seconds. > Database closed in 0.10 seconds. > Database closed in 0.13 seconds. > Database closed in 0.14 seconds. > Disconnecting with v10.12.1.1: > Database closed in 0.74 seconds. > Database closed in 0.87 seconds. > Database closed in 0.76 seconds. > Database closed in 0.87 seconds. > Database closed in 0.85 seconds. > Database closed in 0.69 seconds. > Database closed in 0.84 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6841) Derby v10.12.1.1 is horribly slow compared to v10.11.1.1 in embedded mode
[ https://issues.apache.org/jira/browse/DERBY-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014739#comment-15014739 ] Kathey Marsden commented on DERBY-6841: --- Thanks Xavion for bringing the issue to our attention and filing the new issue. > Derby v10.12.1.1 is horribly slow compared to v10.11.1.1 in embedded mode > - > > Key: DERBY-6841 > URL: https://issues.apache.org/jira/browse/DERBY-6841 > Project: Derby > Issue Type: Bug > Components: JDBC, SQL >Affects Versions: 10.12.1.1 > Environment: OS: Windows, OS X, Linux > CPU: Quad-Core Intel i5 > App: Swing, multi-threaded >Reporter: Xavion > Fix For: 10.11.1.1 > > Attachments: 10.11.1.1.txt, 10.12.1.1-Fresh.txt, 10.12.1.1-Hard.txt, > 10.12.1.1-Soft.txt, DERBY_6841.java > > > It takes much longer to open, read, and close embedded databases using > v10.12.1.1 than it did with v10.11.1.1. What ever changes you guys made over > the last year and a bit have definitely been for the worse. > Below are the results of the repetition tests I've just run on the same > computer with the same databases. Let me know if you need to know about the > sizes of the databases and/or the file type they contain. > Connecting with v10.11.1.1: > Database opened in 0.82 seconds. > Database opened in 0.77 seconds. > Database opened in 0.88 seconds. > Database opened in 0.77 seconds. > Database opened in 0.77 seconds. > Database opened in 0.96 seconds. > Database opened in 0.74 seconds. > Connecting with v10.12.1.1: > Database opened in 1.98 seconds. > Database opened in 2.07 seconds. > Database opened in 1.97 seconds. > Database opened in 2.01 seconds. > Database opened in 2.01 seconds. > Database opened in 2.00 seconds. > Database opened in 2.03 seconds. > Reading with v10.11.1.1: > Database processed in 6.17 seconds. > Database processed in 4.00 seconds. > Database processed in 3.67 seconds. > Database processed in 3.66 seconds. > Database processed in 3.78 seconds. > Database processed in 3.69 seconds. > Database processed in 3.74 seconds. > Reading with v10.12.1.1: > Database processed in 7.29 seconds. > Database processed in 4.54 seconds. > Database processed in 4.88 seconds. > Database processed in 4.65 seconds. > Database processed in 4.34 seconds. > Database processed in 4.35 seconds. > Database processed in 4.50 seconds. > Disconnecting with v10.11.1.1: > Database closed in 0.11 seconds. > Database closed in 0.13 seconds. > Database closed in 0.15 seconds. > Database closed in 0.14 seconds. > Database closed in 0.10 seconds. > Database closed in 0.13 seconds. > Database closed in 0.14 seconds. > Disconnecting with v10.12.1.1: > Database closed in 0.74 seconds. > Database closed in 0.87 seconds. > Database closed in 0.76 seconds. > Database closed in 0.87 seconds. > Database closed in 0.85 seconds. > Database closed in 0.69 seconds. > Database closed in 0.84 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6811) Tasks for producing a 10.12.1 release
[ https://issues.apache.org/jira/browse/DERBY-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14969488#comment-14969488 ] Kathey Marsden commented on DERBY-6811: --- I noticed the jars checked in for upgrade testing did not include derbyrun.jar. Was this intentional? Typically it has been checked in for past releases. > Tasks for producing a 10.12.1 release > - > > Key: DERBY-6811 > URL: https://issues.apache.org/jira/browse/DERBY-6811 > Project: Derby > Issue Type: Task > Components: Miscellaneous >Reporter: Rick Hillegas > Attachments: derby-6811-01-aa-preliminaryReleaseNotes.diff, > derby-6811-02-aa-releaseNotesWith6807.diff, > derby-6811-03-aa-updatedStatus.diff, > derby-6811-04-aa-bumpReleaseIdOnTrunk.diff, > derby-6811-05-aa-updateWebsiteWithNewBranchInfo.diff, > derby-6811-06-aa-releaseNotesOnBranch.diff, > derby-6811-07-aa-simpleJsonNotice.diff, derby-6811-08-newNOTICEfile.diff, > derby-6811-09-aa-trunkDocCopyrightAndVersion.diff, > derby-6811-10-aa-10.12DocCopyrightAndVersion.diff, > derby-6811-11-aa-bumpVersionIdInReleaseNotes.diff, > derby-6811-12-aa-addNewReleaseToUpgradeTests.diff, > derby-6811-13-aa-updateNewsSection.diff, derby-6811-14-aa-updateSTATUS.diff > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-5605. --- Resolution: Fixed Fix Version/s: 10.13.0.0 Thanks Bryan for the review. Committed the change and resolving this issue. > Calling Blob/Clob free() explicitly after implicit free throws exception in > client driver > - > > Key: DERBY-5605 > URL: https://issues.apache.org/jira/browse/DERBY-5605 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.9.1.0 >Reporter: Kristian Waagan >Assignee: Kathey Marsden >Priority: Minor > Labels: derby_triage10_11, derby_triage10_9 > Fix For: 10.13.0.0 > > Attachments: derby-5605_diff.txt, derby-5605_diff.txt > > > If a Blob or Clob is freed implicitly in the client driver, calling free > explicitly afterwards will throw an exception. Instead, this should probably > be a no-op. > To reproduce, do something like this: > con.setAutoCommit(false); > Clob c = con.createClob(); > con.commit(); > c.free(); > ==> > Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other > java.sql.Clob/java.sql.Blob methods after calling the free() method or after > the Blob/Clob's transaction has been committed or rolled back. > at > org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) > at org.apache.derby.client.am.Clob.free(Clob.java:844) > ... 38 more > Caused by: org.apache.derby.client.am.SqlException: The exception > 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is > invalid' was thrown while evaluating an expression. > at > org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) > ... 39 more > Caused by: org.apache.derby.client.am.SqlException: The locator that was > supplied for this CLOB/BLOB is invalid > ... 48 more > The problem dosen't exist in the embedded driver. > The immediate cause seems to be that the client driver state becomes out of > sync with the server side. This may be fixable by dealing specifically witht > the invalid locator exception in free(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6725) Add a system function which returns the name of the database.
[ https://issues.apache.org/jira/browse/DERBY-6725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14961030#comment-14961030 ] Kathey Marsden commented on DERBY-6725: --- Looks like the patch for this issue was committed. Can it be closed? We probably need a new issue to add it to the documentation. > Add a system function which returns the name of the database. > - > > Key: DERBY-6725 > URL: https://issues.apache.org/jira/browse/DERBY-6725 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.12.1.1 >Reporter: Rick Hillegas >Assignee: Mamta A. Satoor > Attachments: DERBY6725_getdbname_patch1_diff.txt, > DERBY6725_getdbname_patch1_stat.txt > > > Got this request in private conversation with a user. Other databases provide > this functionality. Seems straightforward to add. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5794) COMPOUND TRIGGER SUPPORT
[ https://issues.apache.org/jira/browse/DERBY-5794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5794: -- Issue & fix info: (was: Newcomer) > COMPOUND TRIGGER SUPPORT > > > Key: DERBY-5794 > URL: https://issues.apache.org/jira/browse/DERBY-5794 > Project: Derby > Issue Type: Improvement > Components: SQL >Affects Versions: 10.8.1.2 >Reporter: Chirag Mehta >Priority: Minor > Labels: compound, derby_triage10_10, performance, simplex, > trigger > > I tried to search the for support of Compound Triggers like Oracle, didn't > found any support in Derby 10.8 may be this would be a good functionality we > can support. I really like using derby, this is my first project where I > start using derby as an interim database for developers. We have oracle in > production. So if we have compund trigger support with derby it would be grt. > Write now as workaround I am creating 3 triggers (After insert, update and > delete) in derby and 1 in oracle. > If we have compound trigger it would increase the performance also. > Thanks a ton team for your work -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6771) Derby is crashing and writing org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT a
[ https://issues.apache.org/jira/browse/DERBY-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14961017#comment-14961017 ] Kathey Marsden commented on DERBY-6771: --- I think we should close this issue as Cannot Reproduce. We have not heard back from the user in almost a year. > Derby is crashing and writing > org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of > a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error > Code Value = 3. Plaintext connection attempt from an SSL enabled client? > --- > > Key: DERBY-6771 > URL: https://issues.apache.org/jira/browse/DERBY-6771 > Project: Derby > Issue Type: Bug > Components: Network Server >Affects Versions: 10.4.2.0 > Environment: Linux 2.6.18-348.3.1.el5xen x86_64 >Reporter: Sidhant Behura > Labels: Crash, DRDAProtocolException, Derby > > The derby db crashes and writes the following log into derby.out > Execution failed because of a Distributed Protocol Error: > DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error Code Value = 3. Plaintext > connection attempt from an SSL enabled client? > org.apache.derby.impl.drda.DRDAProtocolException: Execution failed because of > a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 0; Error > Code Value = 3. Plaintext connection attempt from an SSL enabled client? > at > org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConnThread.java:513) > at org.apache.derby.impl.drda.DDMReader.readDssHeader(Unknown Source) > at > org.apache.derby.impl.drda.DRDAConnThread.exchangeServerAttributes(DRDAConnThread.java:1109) > at > org.apache.derby.impl.drda.DRDAConnThread.sessionInitialState(DRDAConnThread.java:663) > at > org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:279) > I have observed the PS Perm Generation used space is > 99%. > Please provide some information what is triggering this and how to resolve > this. > Thanks in advance... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-6334) Test harness security policy prevents running DatabaseClassLoadingTest twice
[ https://issues.apache.org/jira/browse/DERBY-6334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14961066#comment-14961066 ] Kathey Marsden commented on DERBY-6334: --- This seems to be resolved. The test runs twice in a row fine for me. It may be related to this fix: r1582655 | kahatlen | 2014-03-28 02:44:37 -0700 (Fri, 28 Mar 2014) | 7 lines DERBY-5615: Permission problems with classpath subsubprotocol Wrap CPFile's privileged operations in doPrivileged() so that classpath databases can be accessed with a security manager. Make more of the test cases in DatabaseClassLoadingTest and NativeAuthenticationServiceTest run with a security manager. Bryan, you ok with resolving this issue? > Test harness security policy prevents running DatabaseClassLoadingTest twice > > > Key: DERBY-6334 > URL: https://issues.apache.org/jira/browse/DERBY-6334 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.11.1.1 >Reporter: Bryan Pendleton >Priority: Minor > > If I try to run DatabaseClassLoadingTest twice in a row, the second run > immediately fails with a AccessControlException. > To reproduce the problem: > 1) cd to a fresh empty directory > 2) java junit.textui.TestRunner > org.apache.derbyTesting.functionTests.tests.lang.DatabaseClassLoadingTest > (test will pass) > 3) java junit.textui.TestRunner > org.apache.derbyTesting.functionTests.tests.lang.DatabaseClassLoadingTest > (test will fail with an AccessControlException) > It's possible that this is due to a problem with the security policy that the > test harness includes for running the unit tests? > I'll include the stack trace in a comment to this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5605: -- Attachment: derby-5605_diff.txt Here is the updated patch. Suites.All and derbyall passed. Please review. > Calling Blob/Clob free() explicitly after implicit free throws exception in > client driver > - > > Key: DERBY-5605 > URL: https://issues.apache.org/jira/browse/DERBY-5605 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.9.1.0 >Reporter: Kristian Waagan >Assignee: Kathey Marsden >Priority: Minor > Labels: derby_triage10_11, derby_triage10_9 > Attachments: derby-5605_diff.txt, derby-5605_diff.txt > > > If a Blob or Clob is freed implicitly in the client driver, calling free > explicitly afterwards will throw an exception. Instead, this should probably > be a no-op. > To reproduce, do something like this: > con.setAutoCommit(false); > Clob c = con.createClob(); > con.commit(); > c.free(); > ==> > Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other > java.sql.Clob/java.sql.Blob methods after calling the free() method or after > the Blob/Clob's transaction has been committed or rolled back. > at > org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) > at org.apache.derby.client.am.Clob.free(Clob.java:844) > ... 38 more > Caused by: org.apache.derby.client.am.SqlException: The exception > 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is > invalid' was thrown while evaluating an expression. > at > org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) > ... 39 more > Caused by: org.apache.derby.client.am.SqlException: The locator that was > supplied for this CLOB/BLOB is invalid > ... 48 more > The problem dosen't exist in the embedded driver. > The immediate cause seems to be that the client driver state becomes out of > sync with the server side. This may be fixable by dealing specifically witht > the invalid locator exception in free(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5605: -- Issue & fix info: High Value Fix,Newcomer,Repro attached,Workaround attached (was: High Value Fix,Newcomer,Patch Available,Repro attached,Workaround attached) Unchecking patch available. Looks like Blob has the same problem. I will post a patch that has a fix for both Clob and Blob. > Calling Blob/Clob free() explicitly after implicit free throws exception in > client driver > - > > Key: DERBY-5605 > URL: https://issues.apache.org/jira/browse/DERBY-5605 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.9.1.0 >Reporter: Kristian Waagan >Assignee: Kathey Marsden >Priority: Minor > Labels: derby_triage10_11, derby_triage10_9 > Attachments: derby-5605_diff.txt > > > If a Blob or Clob is freed implicitly in the client driver, calling free > explicitly afterwards will throw an exception. Instead, this should probably > be a no-op. > To reproduce, do something like this: > con.setAutoCommit(false); > Clob c = con.createClob(); > con.commit(); > c.free(); > ==> > Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other > java.sql.Clob/java.sql.Blob methods after calling the free() method or after > the Blob/Clob's transaction has been committed or rolled back. > at > org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) > at org.apache.derby.client.am.Clob.free(Clob.java:844) > ... 38 more > Caused by: org.apache.derby.client.am.SqlException: The exception > 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is > invalid' was thrown while evaluating an expression. > at > org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) > ... 39 more > Caused by: org.apache.derby.client.am.SqlException: The locator that was > supplied for this CLOB/BLOB is invalid > ... 48 more > The problem dosen't exist in the embedded driver. > The immediate cause seems to be that the client driver state becomes out of > sync with the server side. This may be fixable by dealing specifically witht > the invalid locator exception in free(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-5605: - Assignee: Kathey Marsden > Calling Blob/Clob free() explicitly after implicit free throws exception in > client driver > - > > Key: DERBY-5605 > URL: https://issues.apache.org/jira/browse/DERBY-5605 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.9.1.0 >Reporter: Kristian Waagan >Assignee: Kathey Marsden >Priority: Minor > Labels: derby_triage10_11, derby_triage10_9 > > If a Blob or Clob is freed implicitly in the client driver, calling free > explicitly afterwards will throw an exception. Instead, this should probably > be a no-op. > To reproduce, do something like this: > con.setAutoCommit(false); > Clob c = con.createClob(); > con.commit(); > c.free(); > ==> > Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other > java.sql.Clob/java.sql.Blob methods after calling the free() method or after > the Blob/Clob's transaction has been committed or rolled back. > at > org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) > at org.apache.derby.client.am.Clob.free(Clob.java:844) > ... 38 more > Caused by: org.apache.derby.client.am.SqlException: The exception > 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is > invalid' was thrown while evaluating an expression. > at > org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) > ... 39 more > Caused by: org.apache.derby.client.am.SqlException: The locator that was > supplied for this CLOB/BLOB is invalid > ... 48 more > The problem dosen't exist in the embedded driver. > The immediate cause seems to be that the client driver state becomes out of > sync with the server side. This may be fixable by dealing specifically witht > the invalid locator exception in free(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5605: -- Attachment: derby-5605_diff.txt Attached is a patch and new test for this issue. This changes CLOBRELEASELOCATOR so that it does not throw an exception if the Clob has already been released. > Calling Blob/Clob free() explicitly after implicit free throws exception in > client driver > - > > Key: DERBY-5605 > URL: https://issues.apache.org/jira/browse/DERBY-5605 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.9.1.0 >Reporter: Kristian Waagan >Assignee: Kathey Marsden >Priority: Minor > Labels: derby_triage10_11, derby_triage10_9 > Attachments: derby-5605_diff.txt > > > If a Blob or Clob is freed implicitly in the client driver, calling free > explicitly afterwards will throw an exception. Instead, this should probably > be a no-op. > To reproduce, do something like this: > con.setAutoCommit(false); > Clob c = con.createClob(); > con.commit(); > c.free(); > ==> > Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other > java.sql.Clob/java.sql.Blob methods after calling the free() method or after > the Blob/Clob's transaction has been committed or rolled back. > at > org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) > at org.apache.derby.client.am.Clob.free(Clob.java:844) > ... 38 more > Caused by: org.apache.derby.client.am.SqlException: The exception > 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is > invalid' was thrown while evaluating an expression. > at > org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) > ... 39 more > Caused by: org.apache.derby.client.am.SqlException: The locator that was > supplied for this CLOB/BLOB is invalid > ... 48 more > The problem dosen't exist in the embedded driver. > The immediate cause seems to be that the client driver state becomes out of > sync with the server side. This may be fixable by dealing specifically witht > the invalid locator exception in free(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-5605) Calling Blob/Clob free() explicitly after implicit free throws exception in client driver
[ https://issues.apache.org/jira/browse/DERBY-5605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5605: -- Issue & fix info: High Value Fix,Newcomer,Patch Available,Repro attached,Workaround attached (was: High Value Fix,Newcomer,Repro attached,Workaround attached) > Calling Blob/Clob free() explicitly after implicit free throws exception in > client driver > - > > Key: DERBY-5605 > URL: https://issues.apache.org/jira/browse/DERBY-5605 > Project: Derby > Issue Type: Bug > Components: Network Client >Affects Versions: 10.9.1.0 >Reporter: Kristian Waagan >Assignee: Kathey Marsden >Priority: Minor > Labels: derby_triage10_11, derby_triage10_9 > Attachments: derby-5605_diff.txt > > > If a Blob or Clob is freed implicitly in the client driver, calling free > explicitly afterwards will throw an exception. Instead, this should probably > be a no-op. > To reproduce, do something like this: > con.setAutoCommit(false); > Clob c = con.createClob(); > con.commit(); > c.free(); > ==> > Caused by: org.apache.derby.client.am.SqlException: You cannot invoke other > java.sql.Clob/java.sql.Blob methods after calling the free() method or after > the Blob/Clob's transaction has been committed or rolled back. > at > org.apache.derby.client.am.CallableLocatorProcedures.handleInvalidLocator(CallableLocatorProcedures.java:1071) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:664) > at org.apache.derby.client.am.Clob.free(Clob.java:844) > ... 38 more > Caused by: org.apache.derby.client.am.SqlException: The exception > 'java.sql.SQLException: The locator that was supplied for this CLOB/BLOB is > invalid' was thrown while evaluating an expression. > at > org.apache.derby.client.am.Statement.completeExecute(Statement.java:1604) > at > org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:322) > at > org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:106) > at > org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75) > at > org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:175) > at > org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1570) > at > org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2156) > at > org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1599) > at > org.apache.derby.client.am.CallableLocatorProcedures.clobReleaseLocator(CallableLocatorProcedures.java:662) > ... 39 more > Caused by: org.apache.derby.client.am.SqlException: The locator that was > supplied for this CLOB/BLOB is invalid > ... 48 more > The problem dosen't exist in the embedded driver. > The immediate cause seems to be that the client driver state becomes out of > sync with the server side. This may be fixable by dealing specifically witht > the invalid locator exception in free(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DERBY-6838) LookaheadSuccess in SQLParser leaks caller through backtrace
[ https://issues.apache.org/jira/browse/DERBY-6838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6838: -- Component/s: SQL > LookaheadSuccess in SQLParser leaks caller through backtrace > > > Key: DERBY-6838 > URL: https://issues.apache.org/jira/browse/DERBY-6838 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.11.1.1 >Reporter: Moritz Bechler > > org.apache.derby.impl.sql.compile.SQLParser, which seems to be indefinitly > reused, holds a reference to an instance of LookaheadSuccess, which at least > for OpenJDK holds a strong reference to everything on the initializing caller > stack. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4057) Space is not reclaimed if transaction is rolled back
[ https://issues.apache.org/jira/browse/DERBY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208261#comment-14208261 ] Kathey Marsden commented on DERBY-4057: --- Mike wrote: NUMALLOCATEDPAGES', row 1: Expected: 1001 Found: 1 I just wanted to say Hooray and Thank You Mike! In my time with Derby, I found lack of space reclamation to be the root cause of many support issues. Although an off line compress is usually just a bump in the road, I am excited to see zero admin become more of a reality. DERBY-5473 next! Space is not reclaimed if transaction is rolled back Key: DERBY-4057 URL: https://issues.apache.org/jira/browse/DERBY-4057 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.5.1.1 Reporter: Kathey Marsden Assignee: Mike Matrigali Labels: derby_triage10_5_2, derby_triage10_9 Attachments: DERBY-4057_initial_prototype_patch.diff, DERBY-4057_patch_2.diff If I repeatedly insert into a clob table and rollback the the transaction the space is not reclaimed and the number of allocated pages continues to grow. I will add a test case to ClobReclamationTest and reference this bug. DERBY-4056 may be a special case of this bug, but I thought I would file a bug for the general issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DERBY-4805) Increase the length of the RDBNAM field in the DRDA implementation
[ https://issues.apache.org/jira/browse/DERBY-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871156#comment-13871156 ] Kathey Marsden commented on DERBY-4805: --- One option is to catch the protocol exception in this case and rethrow an SQL exception. The problem with this approach is that it may mask a legitimate protocol error. Another option is to just file a bug for the changed message and leave it. RDBNAM 255 will still work fine and it will just be that the error message is worse with mixed server/client with RDBNAM 255 Increase the length of the RDBNAM field in the DRDA implementation -- Key: DERBY-4805 URL: https://issues.apache.org/jira/browse/DERBY-4805 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Affects Versions: 10.7.1.1 Reporter: Tiago R. Espinha Assignee: Mamta A. Satoor Labels: derby_triage10_9 Attachments: DERBY4805_patch2_diff.txt, DERBY4805_patch2_stat.txt, DERBY_4805_diff_patch1.txt Currently, whenever the client driver is used, there is a limit of 255 bytes for the database name. This is defined by the DRDA spec and there has been a discussion on the list [1]/[2] as to whether this limit should be raised due to the introduction of the new ACR that allows for UTF-8 characters. UTF-8 characters can take up to four bytes and this reduces the limit in characters dramatically. This should be an easy change as there is a codepoint that defines this limit. [1] did not work but [2] did [1] - http://old.nabble.com/Database-name-length-tt29691419.html [2]http://apache-database.10148.n7.nabble.com/Database-name-length-td33182.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DERBY-4805) Increase the length of the RDBNAM field in the DRDA implementation
[ https://issues.apache.org/jira/browse/DERBY-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13865441#comment-13865441 ] Kathey Marsden commented on DERBY-4805: --- Because the database name for Derby as sent with RDBNAM can be the full path and also includes any attributes for the Derby connection, it ends up being more than the name length for most database systems. I think there is a need for it to be larger than 255 bytes. I think though that 1024 should be plenty. Note: A work around if anything larger is needed can be to set derby.system.home to handle the first part of the path. This may be desirable even if under the limit to minimize the RDBNAM since it is sent so frequently. Increase the length of the RDBNAM field in the DRDA implementation -- Key: DERBY-4805 URL: https://issues.apache.org/jira/browse/DERBY-4805 Project: Derby Issue Type: Improvement Components: Network Client, Network Server Affects Versions: 10.7.1.1 Reporter: Tiago R. Espinha Assignee: Mamta A. Satoor Labels: derby_triage10_9 Attachments: DERBY_4805_diff_patch1.txt Currently, whenever the client driver is used, there is a limit of 255 bytes for the database name. This is defined by the DRDA spec and there has been a discussion on the list [1]/[2] as to whether this limit should be raised due to the introduction of the new ACR that allows for UTF-8 characters. UTF-8 characters can take up to four bytes and this reduces the limit in characters dramatically. This should be an easy change as there is a codepoint that defines this limit. [1] did not work but [2] did [1] - http://old.nabble.com/Database-name-length-tt29691419.html [2]http://apache-database.10148.n7.nabble.com/Database-name-length-td33182.html -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (DERBY-4805) Increase the length of the RDBNAM field in the DRDA implementation
[
https://issues.apache.org/jira/browse/DERBY-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13862060#comment-13862060
]
Kathey Marsden commented on DERBY-4805:
---
Hi Mamta,
I think your patch looks good to me except with regard to settling on the new
max size for RDBNAM and making adjustments. I think the total max ddm length
for the PKGNAMCSN will need to be 32767 so you will need to calculate the max
size for the other fields in the PKGNAMCSN (or other DDM objects that contain
RDBNAM).
There is a condition in NetStatementReply which I think needs to be adjusted to
the new length as well.
} else if ((ddmLength = 71) (ddmLength = 781)) {
// this is the new SCLDTA format.
Backing out the current 255 length for RDBNAM, I think that means that the
other fields take 526 bytes so the new limit would be 32,241. We could make it
32,000 just to use a round number.
For the test it would be good to test the new limit which I think you can do
with.
writeScalarPaddedBytes RDBNAM thisNeedsToBeNoMoreThan255CharactersLong #
(where is the new limit)
It would be good also to have a test right at the limit.
I would appreciate another pair of eyes on this patch. It has been a long time
for me since I have done any protocol work.
Increase the length of the RDBNAM field in the DRDA implementation
--
Key: DERBY-4805
URL: https://issues.apache.org/jira/browse/DERBY-4805
Project: Derby
Issue Type: Improvement
Components: Network Client, Network Server
Affects Versions: 10.7.1.1
Reporter: Tiago R. Espinha
Assignee: Mamta A. Satoor
Labels: derby_triage10_9
Attachments: DERBY_4805_diff_patch1.txt
Currently, whenever the client driver is used, there is a limit of 255 bytes
for the database name. This is defined by the DRDA spec and there has been a
discussion on the list [1]/[2] as to whether this limit should be raised due
to the introduction of the new ACR that allows for UTF-8 characters.
UTF-8 characters can take up to four bytes and this reduces the limit in
characters dramatically.
This should be an easy change as there is a codepoint that defines this limit.
[1] did not work but [2] did
[1] - http://old.nabble.com/Database-name-length-tt29691419.html
[2]http://apache-database.10148.n7.nabble.com/Database-name-length-td33182.html
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (DERBY-6415) SYSCS_DIAG.SPACE_TABLE sample query to show all tables and indexes should include schema
[ https://issues.apache.org/jira/browse/DERBY-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838950#comment-13838950 ] Kathey Marsden commented on DERBY-6415: --- Thanks Kim, Change looks good. SYSCS_DIAG.SPACE_TABLE sample query to show all tables and indexes should include schema Key: DERBY-6415 URL: https://issues.apache.org/jira/browse/DERBY-6415 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Assignee: Kim Haase Priority: Trivial Attachments: DERBY-6415.diff, rrefsyscsdiagspacetable.html It would be good if the sample query for SYSCS_DIAG.SPACE_TABLE also showed the schema name as that will be required by SYSCS_UTIL.SYSCS_COMPRESS_TABLE if the tables are compressed. The doc page as at: http://db.apache.org/derby/docs/10.10/ref/rrefsyscsdiagspacetable.html The query for all tables and indexes could be: SELECT sysschemas.schemaname, T2.* FROM SYS.SYSTABLES systabs, SYS.SYSSCHEMAS sysschemas, TABLE (SYSCS_DIAG.SPACE_TABLE()) AS T2 WHERE systabs.tabletype = 'T' AND sysschemas.schemaid = systabs.schemaid AND systabs.tableid = T2.tableid; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-6426) Fix isLoginException
[ https://issues.apache.org/jira/browse/DERBY-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839423#comment-13839423 ] Kathey Marsden commented on DERBY-6426: --- Thanks for fixing this. The change looks good and I ran tests with the IBM JDK and did not see any problems. Fix isLoginException Key: DERBY-6426 URL: https://issues.apache.org/jira/browse/DERBY-6426 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.9.1.0 Reporter: Dave Brosius Assignee: Dave Brosius Priority: Trivial Fix For: 10.1.3.2 Attachments: fix_isLoginException.txt code treats any StandardException as a login exception due to curious no-op code. Added login state check to make it work as expected. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DERBY-6415) SYSCS_DIAG.SPACE_TABLE sample query to show all tables and indexes should include schema
Kathey Marsden created DERBY-6415: - Summary: SYSCS_DIAG.SPACE_TABLE sample query to show all tables and indexes should include schema Key: DERBY-6415 URL: https://issues.apache.org/jira/browse/DERBY-6415 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Priority: Trivial It would be good if the sample query for SYSCS_DIAG.SPACE_TABLE also showed the schema name as that will be required by SYSCS_UTIL.SYSCS_COMPRESS_TABLE if the tables are compressed. The doc page as at: http://db.apache.org/derby/docs/10.10/ref/rrefsyscsdiagspacetable.html The query for all tables and indexes could be: SELECT sysschemas.schemaname, T2.* FROM SYS.SYSTABLES systabs, SYS.SYSSCHEMAS sysschemas, TABLE (SYSCS_DIAG.SPACE_TABLE()) AS T2 WHERE systabs.tabletype = 'T' AND sysschemas.schemaid = systabs.schemaid AND systabs.tableid = T2.tableid; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DERBY-6416) Document upgrade procedures for replication
Kathey Marsden created DERBY-6416: - Summary: Document upgrade procedures for replication Key: DERBY-6416 URL: https://issues.apache.org/jira/browse/DERBY-6416 Project: Derby Issue Type: Improvement Components: Documentation Reporter: Kathey Marsden On the user list there was a report of difficulty upgrading from 10.8 to 10.10 with replication. We don't have any documentation on special procedures needed for upgrade with replication, but it seems there may be some special handling required. It would be good if we could determine what steps are required to upgrade with replication and document them. http://apache-database.10148.n7.nabble.com/Upgrade-from-10-8-2-3-to-10-10-1-3-td135345.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DERBY-6401) Create a test option to stop running Junit tests after first failure or error
[ https://issues.apache.org/jira/browse/DERBY-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-6401. --- Resolution: Fixed Fix Version/s: 10.11.0.0 10.10.1.3 Create a test option to stop running Junit tests after first failure or error - Key: DERBY-6401 URL: https://issues.apache.org/jira/browse/DERBY-6401 Project: Derby Issue Type: Improvement Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Fix For: 10.10.1.3, 10.11.0.0 Attachments: derby-6401_diff.txt Sometimes when debugging issues, it would be convenient to have the tests stop after the first failure or error. Add System property option derby.tests.stopAfterFirstFail to do this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-6349) DaylightSavingTest - java.security.AccessControlException
[ https://issues.apache.org/jira/browse/DERBY-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819151#comment-13819151 ] Kathey Marsden commented on DERBY-6349: --- Note: Commit 1525671 is the correct 10.10 commit for this issue. 1526486 was for another issue with an incorrect comment (now corrected in svn), but cannot delete the comment in this issue. DaylightSavingTest - java.security.AccessControlException - Key: DERBY-6349 URL: https://issues.apache.org/jira/browse/DERBY-6349 Project: Derby Issue Type: Bug Environment: IBM internal prerelease JVM Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.10.1.3, 10.11.0.0 Attachments: TimeZoneSecurity_diff.txt Seeing this test failure because of an intentional security change in TimeZone.setDefault(). Therefore need to wrap Timezone.setDefault in a priv block in the test. 1) DaylightSavingTestjava.security.AccessControlException: Access denied (java.util.PropertyPermission user.timezone write) at java.security.AccessController.throwACE(AccessController.java:10 0) at unknown class.unknown method(Unknown Source) at java.lang.SecurityManager.checkPermission(SecurityManager.java:5 49) at java.util.TimeZone.hasPermission(TimeZone.java:756) at java.util.TimeZone.setDefault(TimeZone.java:778) at org.apache.derbyTesting.junit.TimeZoneTestSetup.setUp(TimeZoneTe stSetup.java:59) at junit.extensions.TestSetup$1.protect(TestSetup.java:22) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.ja va:57) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-6349) DaylightSavingTest - java.security.AccessControlException
[ https://issues.apache.org/jira/browse/DERBY-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6349: -- Fix Version/s: 10.9.2.2 10.8.3.1 10.7.1.4 10.6.2.2 backported to 10.6. Test does not exist in older branches. DaylightSavingTest - java.security.AccessControlException - Key: DERBY-6349 URL: https://issues.apache.org/jira/browse/DERBY-6349 Project: Derby Issue Type: Bug Environment: IBM internal prerelease JVM Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.6.2.2, 10.7.1.4, 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0 Attachments: TimeZoneSecurity_diff.txt Seeing this test failure because of an intentional security change in TimeZone.setDefault(). Therefore need to wrap Timezone.setDefault in a priv block in the test. 1) DaylightSavingTestjava.security.AccessControlException: Access denied (java.util.PropertyPermission user.timezone write) at java.security.AccessController.throwACE(AccessController.java:10 0) at unknown class.unknown method(Unknown Source) at java.lang.SecurityManager.checkPermission(SecurityManager.java:5 49) at java.util.TimeZone.hasPermission(TimeZone.java:756) at java.util.TimeZone.setDefault(TimeZone.java:778) at org.apache.derbyTesting.junit.TimeZoneTestSetup.setUp(TimeZoneTe stSetup.java:59) at junit.extensions.TestSetup$1.protect(TestSetup.java:22) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.ja va:57) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (DERBY-6401) Create a test option to stop running Junit tests after first failure or error
[ https://issues.apache.org/jira/browse/DERBY-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-6401: - Assignee: Kathey Marsden Create a test option to stop running Junit tests after first failure or error - Key: DERBY-6401 URL: https://issues.apache.org/jira/browse/DERBY-6401 Project: Derby Issue Type: Improvement Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Attachments: derby-6401_diff.txt Sometimes when debugging issues, it would be convenient to have the tests stop after the first failure or error. Add System property option derby.tests.stopAfterFirstFail to do this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DERBY-6294) On z/os on some machines:testAttributeDrdaHost(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)junit.framework.AssertionFailedError
[
https://issues.apache.org/jira/browse/DERBY-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden resolved DERBY-6294.
---
Resolution: Fixed
Fix Version/s: 10.11.0.0
10.10.1.3
On z/os on some
machines:testAttributeDrdaHost(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)junit.framework.AssertionFailedError
--
Key: DERBY-6294
URL: https://issues.apache.org/jira/browse/DERBY-6294
Project: Derby
Issue Type: Bug
Environment: IBM 1.7 z/OS
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Fix For: 10.10.1.3, 10.11.0.0
Attachments: DERBY-6294_diff.txt
1)
testAttributeDrdaHost(org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest)junit.framework.AssertionFailedError
at
org.apache.derbyTesting.functionTests.tests.management.NetworkServerMBeanTest.testAttributeDrdaHost(NetworkServerMBeanTest.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
The failure is on the assertion below.
if (serverHost.equals(localhost) || serverHost.equals(127.0.0.1))
{
String mbeanHost = (String) getAttribute(
getNetworkServerMBeanObjectName(),
DrdaHost);
assertNotNull(mbeanHost);
assertTrue(mbeanHost.equals(localhost)
|| mbeanHost.equals(127.0.0.1));
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (DERBY-6401) Create a test option to stop running Junit tests after first failure or error
Kathey Marsden created DERBY-6401: - Summary: Create a test option to stop running Junit tests after first failure or error Key: DERBY-6401 URL: https://issues.apache.org/jira/browse/DERBY-6401 Project: Derby Issue Type: Improvement Reporter: Kathey Marsden Priority: Minor Sometimes when debugging issues, it would be convenient to have the tests stop after the first failure or error. Add System property option derby.tests.stopAfterFirstFail to do this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-6401) Create a test option to stop running Junit tests after first failure or error
[ https://issues.apache.org/jira/browse/DERBY-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6401: -- Issue fix info: Patch Available Create a test option to stop running Junit tests after first failure or error - Key: DERBY-6401 URL: https://issues.apache.org/jira/browse/DERBY-6401 Project: Derby Issue Type: Improvement Reporter: Kathey Marsden Priority: Minor Attachments: derby-6401_diff.txt Sometimes when debugging issues, it would be convenient to have the tests stop after the first failure or error. Add System property option derby.tests.stopAfterFirstFail to do this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-6401) Create a test option to stop running Junit tests after first failure or error
[ https://issues.apache.org/jira/browse/DERBY-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6401: -- Attachment: derby-6401_diff.txt Here is a patch that makes this change. It is a bit hokey the way it just abruptly exits in BaseTestCase.runBare(). I suppose the cleaner way to do it is to make a TestRunner to extend junit.textui.TestRunner, but that would not be something I could check in. Anyway, please review and let me know if you object to this change or see a better way. I noticed the ant task for junit has a haltonerror and haltonfailure attributes but don't see anything for the junit.textui.TestRunner Create a test option to stop running Junit tests after first failure or error - Key: DERBY-6401 URL: https://issues.apache.org/jira/browse/DERBY-6401 Project: Derby Issue Type: Improvement Reporter: Kathey Marsden Priority: Minor Attachments: derby-6401_diff.txt Sometimes when debugging issues, it would be convenient to have the tests stop after the first failure or error. Add System property option derby.tests.stopAfterFirstFail to do this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (DERBY-6395) SYSCS_UTIL.SYSCS_COMPRESS_TABLE message for not found table says: 'ALTER TABLE' cannot be performed
Kathey Marsden created DERBY-6395:
-
Summary: SYSCS_UTIL.SYSCS_COMPRESS_TABLE message for not found
table says: 'ALTER TABLE' cannot be performed
Key: DERBY-6395
URL: https://issues.apache.org/jira/browse/DERBY-6395
Project: Derby
Issue Type: Bug
Components: SQL
Affects Versions: 10.11.0.0
Reporter: Kathey Marsden
Priority: Trivial
For historical reasons SYCSCS_UTIL.SYSCS_COMPRESS_TABLE gives a not very
sensible message. The user did not actually execute an ALTER TABLE command.
ij CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE('APP','NOTTHERE',1);
ERROR 38000: The exception 'java.sql.SQLException: 'ALTER TABLE' cannot be
performed on 'APP.NOTTHERE' because it does n
ot exist.' was thrown while evaluating an expression.
ERROR 42Y55: 'ALTER TABLE' cannot be performed on 'APP.NOTTHERE' because it
does not exist.
ij
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (DERBY-2813) store/ClassLoaderBootTest fixture testBootingAnAlreadyBootedDatabase fails indicating derby booted a database that was already booted by another CLR if security manager i
[ https://issues.apache.org/jira/browse/DERBY-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2813: -- Attachment: derby-2813_betterassert_diff.txt Attaching a patch that just gives a better assert when run with security manager. The new assertion shows that the ClassLoader of the datasource is wrong instead of indicating dual boot. Also changes an instance of getContextClassLoader to be in a privilege block and fixes up a couple comments. I can't quite figure out why we are not getting the right class loader with security manager. setContextClassLoader seems to be executing properly but for some reason the instantiated data source does not pick it up, but I will go ahead and check in this patch as at least it makes the real problem clearer. The new failure with security manager on is 1) testBootingAnAlreadyBootedDatabase(org.apache.derbyTesting.functionTests.tests.store.ClassLoaderBootTest)junit.framew ork.AssertionFailedError: expected:org.apache.derbyTesting.functionTests.tests.store.ClassLoaderBootTest$DerbyURLClassL oader@b1b0b1b but was:sun.misc.Launcher$AppClassLoader@1e261e26 at org.apache.derbyTesting.functionTests.tests.store.ClassLoaderBootTest.testBootingAnAlreadyBootedDatabase(Clas sLoaderBootTest.java:174) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) 2) testBootingDatabaseShutdownByAnotherCLR(org.apache.derbyTesting.functionTests.tests.store.ClassLoaderBootTest)junit.f ramework.AssertionFailedError: expected:org.apache.derbyTesting.functionTests.tests.store.ClassLoaderBootTest$DerbyURLC lassLoader@48874887 but was:sun.misc.Launcher$AppClassLoader@1e261e26 at org.apache.derbyTesting.functionTests.tests.store.ClassLoaderBootTest.testBootingDatabaseShutdownByAnotherCLR (ClassLoaderBootTest.java:207) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) FAILURES!!! Tests run: 2, Failures: 2, Errors: 0 store/ClassLoaderBootTest fixture testBootingAnAlreadyBootedDatabase fails indicating derby booted a database that was already booted by another CLR if security manager is on -- Key: DERBY-2813 URL: https://issues.apache.org/jira/browse/DERBY-2813 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.1.4, 10.11.0.0 Environment: The test ClassLoaderBoot test currently runs without security manager. Security manager needs to be enabled. Reporter: Kathey Marsden Labels: derby_triage10_11 Attachments: derby-2813_betterassert_diff.txt -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-532) Support deferrable constraints
[ https://issues.apache.org/jira/browse/DERBY-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802983#comment-13802983 ] Kathey Marsden commented on DERBY-532: -- That makes sense to me as I believe once prepared, nothing should interfere with the commit, but I say that just from what seems logical, not having done any spec or product research on the matter. Support deferrable constraints -- Key: DERBY-532 URL: https://issues.apache.org/jira/browse/DERBY-532 Project: Derby Issue Type: Improvement Components: SQL Reporter: Jörg von Frantzius Assignee: Dag H. Wanvik Labels: derby_triage10_11 Attachments: deferredConstraints.html, deferredConstraints.html, derby-532-syntax-binding-dict-1.diff, derby-532-syntax-binding-dict-1.status, derby-532-syntax-binding-dict-2.diff, derby-532-syntax-binding-dict-2.status, derby-532-syntax-binding-dict-all-1.diff, derby-532-testAlterConstraintInvalidation.diff, derby-532-testAlterConstraintInvalidation.status, derby-532-unique-pk-1.diff, derby-532-unique-pk-1.status In many situations it is desirable to have constraints checking taking place only at transaction commit time, and not before. If e.g. there is a chain of foreign key constraints between tables, insert statements have to be ordered to avoid constraint violations. If foreign key references are circular, the DML has to be split into insert statements and subsequent update statements by the user. In other words, with deferred constraints checking, life is much easier for the user. Also it can create problems with softwares such as object-relational mapping tools that are not prepared for statement ordering and thus depend on deferred constraints checking. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2
[ https://issues.apache.org/jira/browse/DERBY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13803544#comment-13803544 ] Kathey Marsden commented on DERBY-2130: --- I tried patched 10.2 and found the prepare was 13 seconds, so it seems this patch did resolve the original performance regression. On patched 10.3 the prepare was 69 seconds, so I guess there was an additional slow down from 10.2 to 10.3 which we are still seeing on trunk 10.11. I will resolve this issue and open another one for the 10.2 to 10.3 performance slow down. Optimizer performance slowdown from 10.1 to 10.2 Key: DERBY-2130 URL: https://issues.apache.org/jira/browse/DERBY-2130 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4 Reporter: Bryan Pendleton Labels: derby_triage10_11 Attachments: jumpReset_10_11_trunk_diff.txt, jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt, plans.diff, repro.sql Attached is 'repro.sql', an IJ script which demonstrates what I believe to be a serious performance issue in the Optimizer. I have run this script in a number of configurations: - 10.1.2.1: the script runs successfully. The 'prepare' statement takes about 90 seconds, on a fairly powerful Windows machine - 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777 - 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement often takes about 220 seconds, on the same Windows machine Intermittently, on 10.2 and on the trunk, the prepare statement takes 15+ minutes. I cannot reliably reproduce this; I run the same script several times in a row and I cannot predict whether it will take 220 seconds or whether it will take 15+ minutes. I am quite motivated to work on this problem, as this is blocking me from using Derby for a project that I'm quite keen on, but I need some suggestions and ideas about how to attack it. From my perspective there are 3 primary topics: 1) Why did optimizer performance for this query degrade so significantly from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower, for this particular query at least, in 10.2. Sometimes it is 10x slower. 2) What is the source of the non-determinism? Why does the optimizer often take 4 minutes to optimize this query on the trunk, but sometimes take 15+ minutes? I don't believe that I'm changing anything from run to run. 3) Can we improve the optimizer performance even beyond what it was for 10.1.2? I realize that this is an ugly query, but I was hoping to see an optimization time of 5-10 seconds, not 90 seconds (and certainly not 220 seconds). I have attempted to start answering some of these questions, with limited success. Here is some of what I think I've discovered so far: - the optimizer changes in 10.2 seem to have given the optimizer many more choices of possible query plans to consider. I think this means that, if the optimizer does not time out, it will spend substantially more time optimizing because there are more choices to evaluate. Does this by itself mean that the optimizer will take 2.5 times longer in 10.2 than it did in 10.1? - something about this query seems to make the costing mechanism go haywire, and produce extreme costs. While stepping through the optimization of this query in the debugger I have seen it compute costs like 1e63 and 1e200. This might be very closely related to DERBY-1905, although I don't think I'm doing any subqueries here. But maybe I'm misunderstanding the term subquery in DERBY-1905. At any rate, due to the enormous estimated costs, timeout does not occur. - the WHERE clause in this query is converted during compilation to an equivalent IN clause, I believe, which then causes me to run into a number of the problems described in DERBY-47 and DERBY-713. Specifically, rather than constructing a plan which involves 4 index probes for the 4 WHERE clause values, the optimizer decides that an index scan must be performed and that it will have to process the entire index (because the query uses parameter markers, not literal values). So perhaps solving DERBY-47 would help me - the optimizer in fact comes up with a decent query plan quite quickly. I have experimented with placing a hard limit into the optimizer timeout code, so that I can force optimization to stop after an arbitrary fixed period of time. Then I have been able to set that value to as low as 1 second, and the optimizer has produced plans that then execute in a few milliseconds. Of course, I have only tried this with a trivial amount of data in my database, so it's possible that the plan produced by
[jira] [Created] (DERBY-6392) Optimizer slowdown from 10.2 to 10.3 (masked by DERBY-2130)
Kathey Marsden created DERBY-6392: - Summary: Optimizer slowdown from 10.2 to 10.3 (masked by DERBY-2130) Key: DERBY-6392 URL: https://issues.apache.org/jira/browse/DERBY-6392 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.10.1.1, 10.3.3.1, 10.4.2.1, 10.5.3.1, 10.6.2.2, 10.7.1.4, 10.8.3.1, 10.9.2.2, 10.11.0.0 Environment: After the DERBY-2130 fix in trunk (10.11) I noticed that the repro attached to the issue (repro.sql) ran significantly slower on 10.11 vs 10.1 or 10.2 with the patch. I tried the patch with 10.3 and found that the query ran slower there. 10.1 - 13 seconds 10.2 with patch - 10 seconds 10.3 with patch - 69 seconds 10.11 with patch - 69 seconds So there must have been some slowdown between 10.2 and 10.3 that was masked by the DERBY-2130 bug. To reproduce on 10.3 Merge the DERBY-2130 fix from trunk svn merge -x -b -c 1534465 https://svn.apache.org/repos/asf/db/derby/code/trunk Run repro.sql attached to DERBY-2130 Reporter: Kathey Marsden -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2
[ https://issues.apache.org/jira/browse/DERBY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-2130. --- Resolution: Fixed Fix Version/s: 10.11.0.0 Fixing just in trunk for now to monitor any performance change. Fix should be suitable for backport. Optimizer performance slowdown from 10.1 to 10.2 Key: DERBY-2130 URL: https://issues.apache.org/jira/browse/DERBY-2130 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4 Reporter: Bryan Pendleton Labels: derby_triage10_11 Fix For: 10.11.0.0 Attachments: jumpReset_10_11_trunk_diff.txt, jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt, plans.diff, repro.sql Attached is 'repro.sql', an IJ script which demonstrates what I believe to be a serious performance issue in the Optimizer. I have run this script in a number of configurations: - 10.1.2.1: the script runs successfully. The 'prepare' statement takes about 90 seconds, on a fairly powerful Windows machine - 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777 - 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement often takes about 220 seconds, on the same Windows machine Intermittently, on 10.2 and on the trunk, the prepare statement takes 15+ minutes. I cannot reliably reproduce this; I run the same script several times in a row and I cannot predict whether it will take 220 seconds or whether it will take 15+ minutes. I am quite motivated to work on this problem, as this is blocking me from using Derby for a project that I'm quite keen on, but I need some suggestions and ideas about how to attack it. From my perspective there are 3 primary topics: 1) Why did optimizer performance for this query degrade so significantly from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower, for this particular query at least, in 10.2. Sometimes it is 10x slower. 2) What is the source of the non-determinism? Why does the optimizer often take 4 minutes to optimize this query on the trunk, but sometimes take 15+ minutes? I don't believe that I'm changing anything from run to run. 3) Can we improve the optimizer performance even beyond what it was for 10.1.2? I realize that this is an ugly query, but I was hoping to see an optimization time of 5-10 seconds, not 90 seconds (and certainly not 220 seconds). I have attempted to start answering some of these questions, with limited success. Here is some of what I think I've discovered so far: - the optimizer changes in 10.2 seem to have given the optimizer many more choices of possible query plans to consider. I think this means that, if the optimizer does not time out, it will spend substantially more time optimizing because there are more choices to evaluate. Does this by itself mean that the optimizer will take 2.5 times longer in 10.2 than it did in 10.1? - something about this query seems to make the costing mechanism go haywire, and produce extreme costs. While stepping through the optimization of this query in the debugger I have seen it compute costs like 1e63 and 1e200. This might be very closely related to DERBY-1905, although I don't think I'm doing any subqueries here. But maybe I'm misunderstanding the term subquery in DERBY-1905. At any rate, due to the enormous estimated costs, timeout does not occur. - the WHERE clause in this query is converted during compilation to an equivalent IN clause, I believe, which then causes me to run into a number of the problems described in DERBY-47 and DERBY-713. Specifically, rather than constructing a plan which involves 4 index probes for the 4 WHERE clause values, the optimizer decides that an index scan must be performed and that it will have to process the entire index (because the query uses parameter markers, not literal values). So perhaps solving DERBY-47 would help me - the optimizer in fact comes up with a decent query plan quite quickly. I have experimented with placing a hard limit into the optimizer timeout code, so that I can force optimization to stop after an arbitrary fixed period of time. Then I have been able to set that value to as low as 1 second, and the optimizer has produced plans that then execute in a few milliseconds. Of course, I have only tried this with a trivial amount of data in my database, so it's possible that the plan produced by the optimizer after just a second of optimizing is in fact poor, and I'm just not noticing it because my data sizes are so small. At this point, what would be really helpful to me would be some suggestions about some general
[jira] [Commented] (DERBY-6115) Certain OR expressions are not passed to Table indexes or Table Function initScan()
[ https://issues.apache.org/jira/browse/DERBY-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801972#comment-13801972 ] Kathey Marsden commented on DERBY-6115: --- Is the IN list portion the same as https://issues.apache.org/jira/browse/DERBY-6301 ? Certain OR expressions are not passed to Table indexes or Table Function initScan() --- Key: DERBY-6115 URL: https://issues.apache.org/jira/browse/DERBY-6115 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2, 10.8.2.2, 10.8.3.0, 10.9.1.0, 10.10.1.1 Reporter: David Vyvyan Labels: derby_triage10_11 Issue originally posted here: http://apache-database.10148.n7.nabble.com/RestrictedVTI-initScan-does-not-pass-certain-Table-Functions-predicate-expressions-td128229.html Note by Rick Hillegas: Hi David, I think it's worth filing a JIRA for this issue. If the defect is shared by VTIs and table functions then there's a possibility that ordinary table scans suffer from it too. That would raise the problem's urgency. Thanks, -Rick Summary Description: Basically some WHERE clause expressions do not get passed through via RestrictedVTI.initScan(). This can have a severe impact on memory/performance. (I suspect the issue may be related to logic which tries to move AND nodes to the top of the tree...?) Examples (I have a few more here than in the post above): These get passed ok in the Restriction object: - C16 - C11 AND C2'd' - C16 OR C2'd' - C11 AND (C16 OR C2'd') This one gets passed partially by initScan(): C11 AND (C16 OR (C2'e' AND C2'd'))===initScan() passes only: C1 1 These do not get passed at all (initScan() Restriction argument object is null): - C16 OR (C11 AND C2'd') - C16 OR ((C11 AND C2'd') AND C2'b') - C1 in ( 1, 4 ) - C1 in ( 1, 4 ) OR C2'f' -- Can Derby resolve in() clauses to a list of '=' conditions ? This would be useful! My table function is defined as follows: CREATE FUNCTION TF_TEST1() RETURNS TABLE(C1 INT, C2 VARCHAR(32672)) PARAMETER STYLE DERBY_JDBC_RESULT_SET LANGUAGE JAVA NOT DETERMINISTIC READS SQL DATA EXTERNAL NAME 'core.TestTableFunctions.TF_TEST1' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2
[ https://issues.apache.org/jira/browse/DERBY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800791#comment-13800791 ] Kathey Marsden commented on DERBY-2130: --- So should I go ahead and check this in as is if tests pass? If so, should it go back to 10.10? We aren't really set up for performance regression tests so I am not really sure what testing we could add. Optimizer performance slowdown from 10.1 to 10.2 Key: DERBY-2130 URL: https://issues.apache.org/jira/browse/DERBY-2130 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4 Reporter: Bryan Pendleton Labels: derby_triage10_11 Attachments: jumpReset_10_11_trunk_diff.txt, jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt, plans.diff, repro.sql Attached is 'repro.sql', an IJ script which demonstrates what I believe to be a serious performance issue in the Optimizer. I have run this script in a number of configurations: - 10.1.2.1: the script runs successfully. The 'prepare' statement takes about 90 seconds, on a fairly powerful Windows machine - 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777 - 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement often takes about 220 seconds, on the same Windows machine Intermittently, on 10.2 and on the trunk, the prepare statement takes 15+ minutes. I cannot reliably reproduce this; I run the same script several times in a row and I cannot predict whether it will take 220 seconds or whether it will take 15+ minutes. I am quite motivated to work on this problem, as this is blocking me from using Derby for a project that I'm quite keen on, but I need some suggestions and ideas about how to attack it. From my perspective there are 3 primary topics: 1) Why did optimizer performance for this query degrade so significantly from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower, for this particular query at least, in 10.2. Sometimes it is 10x slower. 2) What is the source of the non-determinism? Why does the optimizer often take 4 minutes to optimize this query on the trunk, but sometimes take 15+ minutes? I don't believe that I'm changing anything from run to run. 3) Can we improve the optimizer performance even beyond what it was for 10.1.2? I realize that this is an ugly query, but I was hoping to see an optimization time of 5-10 seconds, not 90 seconds (and certainly not 220 seconds). I have attempted to start answering some of these questions, with limited success. Here is some of what I think I've discovered so far: - the optimizer changes in 10.2 seem to have given the optimizer many more choices of possible query plans to consider. I think this means that, if the optimizer does not time out, it will spend substantially more time optimizing because there are more choices to evaluate. Does this by itself mean that the optimizer will take 2.5 times longer in 10.2 than it did in 10.1? - something about this query seems to make the costing mechanism go haywire, and produce extreme costs. While stepping through the optimization of this query in the debugger I have seen it compute costs like 1e63 and 1e200. This might be very closely related to DERBY-1905, although I don't think I'm doing any subqueries here. But maybe I'm misunderstanding the term subquery in DERBY-1905. At any rate, due to the enormous estimated costs, timeout does not occur. - the WHERE clause in this query is converted during compilation to an equivalent IN clause, I believe, which then causes me to run into a number of the problems described in DERBY-47 and DERBY-713. Specifically, rather than constructing a plan which involves 4 index probes for the 4 WHERE clause values, the optimizer decides that an index scan must be performed and that it will have to process the entire index (because the query uses parameter markers, not literal values). So perhaps solving DERBY-47 would help me - the optimizer in fact comes up with a decent query plan quite quickly. I have experimented with placing a hard limit into the optimizer timeout code, so that I can force optimization to stop after an arbitrary fixed period of time. Then I have been able to set that value to as low as 1 second, and the optimizer has produced plans that then execute in a few milliseconds. Of course, I have only tried this with a trivial amount of data in my database, so it's possible that the plan produced by the optimizer after just a second of optimizing is in fact poor, and I'm just not noticing it because my data sizes are so small. At this point, what would be really
[jira] [Created] (DERBY-6386) Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath
Kathey Marsden created DERBY-6386: - Summary: Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath Key: DERBY-6386 URL: https://issues.apache.org/jira/browse/DERBY-6386 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.11.0.0 Reporter: Kathey Marsden I see the following errors in jdbc4.LobStreamTest if derbyclient.jar is before derby.jar on trunk 10.11 Rev: 1533320 There were 2 errors: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClass DefFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBStreamControl.write(LOBStreamControl.java:237) at org.apache.derby.impl.jdbc.LOBOutputStream.write(LOBOutputStream.java:108) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) 2) testReadWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClassD efFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBInputStream.read(LOBInputStream.java:133) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testReadWithInvalidParameterValues(LobStreamT est.java:384) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) There were 2 failures: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)junit.framework.A ssertionFailedError: Expected IndexOutOfBoundException at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:305) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) 2) testReadWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)junit.framework.As sertionFailedError: Expected IndexOutOfBoundException
[jira] [Commented] (DERBY-6386) Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath
[ https://issues.apache.org/jira/browse/DERBY-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801090#comment-13801090 ] Kathey Marsden commented on DERBY-6386: --- Looks like this happened as part of DERBY-5317. I will change Request.java to use import org.apache.derby.shared.common.error.ExceptionUtil; instead. Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath -- Key: DERBY-6386 URL: https://issues.apache.org/jira/browse/DERBY-6386 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.11.0.0 Reporter: Kathey Marsden I see the following errors in jdbc4.LobStreamTest if derbyclient.jar is before derby.jar on trunk 10.11 Rev: 1533320 There were 2 errors: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClass DefFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBStreamControl.write(LOBStreamControl.java:237) at org.apache.derby.impl.jdbc.LOBOutputStream.write(LOBOutputStream.java:108) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) 2) testReadWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClassD efFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBInputStream.read(LOBInputStream.java:133) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testReadWithInvalidParameterValues(LobStreamT est.java:384) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) There were 2 failures: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)junit.framework.A ssertionFailedError: Expected IndexOutOfBoundException at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:305) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
[jira] [Assigned] (DERBY-6386) Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath
[ https://issues.apache.org/jira/browse/DERBY-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-6386: - Assignee: Kathey Marsden Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath -- Key: DERBY-6386 URL: https://issues.apache.org/jira/browse/DERBY-6386 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.11.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden I see the following errors in jdbc4.LobStreamTest if derbyclient.jar is before derby.jar on trunk 10.11 Rev: 1533320 There were 2 errors: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClass DefFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBStreamControl.write(LOBStreamControl.java:237) at org.apache.derby.impl.jdbc.LOBOutputStream.write(LOBOutputStream.java:108) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) 2) testReadWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClassD efFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBInputStream.read(LOBInputStream.java:133) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testReadWithInvalidParameterValues(LobStreamT est.java:384) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) There were 2 failures: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)junit.framework.A ssertionFailedError: Expected IndexOutOfBoundException at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:305) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at
[jira] [Commented] (DERBY-6386) Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath
[ https://issues.apache.org/jira/browse/DERBY-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801105#comment-13801105 ] Kathey Marsden commented on DERBY-6386: --- We tend to hit these from time to time. I wonder if it would be feasible for one of the nightly runs to put derbyclient.jar first. Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath -- Key: DERBY-6386 URL: https://issues.apache.org/jira/browse/DERBY-6386 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.11.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden I see the following errors in jdbc4.LobStreamTest if derbyclient.jar is before derby.jar on trunk 10.11 Rev: 1533320 There were 2 errors: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClass DefFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBStreamControl.write(LOBStreamControl.java:237) at org.apache.derby.impl.jdbc.LOBOutputStream.write(LOBOutputStream.java:108) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) 2) testReadWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClassD efFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBInputStream.read(LOBInputStream.java:133) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testReadWithInvalidParameterValues(LobStreamT est.java:384) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) There were 2 failures: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)junit.framework.A ssertionFailedError: Expected IndexOutOfBoundException at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:305) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at
[jira] [Resolved] (DERBY-6386) Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath
[ https://issues.apache.org/jira/browse/DERBY-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-6386. --- Resolution: Fixed Fix Version/s: 10.11.0.0 Errors in jdbc4.LobStreamTest if derbyclient.jar is first in the classpath -- Key: DERBY-6386 URL: https://issues.apache.org/jira/browse/DERBY-6386 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.11.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.11.0.0 I see the following errors in jdbc4.LobStreamTest if derbyclient.jar is before derby.jar on trunk 10.11 Rev: 1533320 There were 2 errors: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClass DefFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBStreamControl.write(LOBStreamControl.java:237) at org.apache.derby.impl.jdbc.LOBOutputStream.write(LOBOutputStream.java:108) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:302) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) 2) testReadWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)java.lang.NoClassD efFoundError: org/apache/derby/iapi/error/ExceptionUtil at org.apache.derby.impl.jdbc.LOBInputStream.read(LOBInputStream.java:133) at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testReadWithInvalidParameterValues(LobStreamT est.java:384) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) There were 2 failures: 1) testWriteWithInvalidParameterValues(org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest)junit.framework.A ssertionFailedError: Expected IndexOutOfBoundException at org.apache.derbyTesting.functionTests.tests.jdbc4.LobStreamTest.testWriteWithInvalidParameterValues(LobStream Test.java:305) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at
[jira] [Commented] (DERBY-6283) indexStat daemon processing tables over and over even when there are no changes in the tables in soft upgraded database.
[ https://issues.apache.org/jira/browse/DERBY-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800146#comment-13800146 ] Kathey Marsden commented on DERBY-6283: --- Mike, can this issue be resolved? Looks like it was fixed and backported through 10.8. indexStat daemon processing tables over and over even when there are no changes in the tables in soft upgraded database. Key: DERBY-6283 URL: https://issues.apache.org/jira/browse/DERBY-6283 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0 Reporter: Mike Matrigali Assignee: Mike Matrigali Priority: Blocker Labels: derby_triage10_11 Fix For: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0 Attachments: derby-6283.diff The fix for DERBY-5680 currently requires hard upgrade. A soft upgrade database with an orphaned stat row, that can be caused by something like DERBY-5681, will cause DERBY to spin eating up 100% of a cpu and possibly all the disk bandwith of the disk where the database is located. We should implement a fix that can be applied to soft upgraded databases if at all possible. In soft upgraded databases we can no use the work around of dropping the statistics as it is not available to soft upgraded db's with version 10.9. The only current workaround is to disable background stats completely. Dropping and recreating the suspect table may also work. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2
[ https://issues.apache.org/jira/browse/DERBY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800149#comment-13800149 ] Kathey Marsden commented on DERBY-2130: --- Verified this is still a problem. On my machine the 10.1 query takes 13 seconds but 203 seconds on trunk. Optimizer performance slowdown from 10.1 to 10.2 Key: DERBY-2130 URL: https://issues.apache.org/jira/browse/DERBY-2130 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4 Reporter: Bryan Pendleton Labels: derby_triage10_11 Attachments: jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt, plans.diff, repro.sql Attached is 'repro.sql', an IJ script which demonstrates what I believe to be a serious performance issue in the Optimizer. I have run this script in a number of configurations: - 10.1.2.1: the script runs successfully. The 'prepare' statement takes about 90 seconds, on a fairly powerful Windows machine - 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777 - 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement often takes about 220 seconds, on the same Windows machine Intermittently, on 10.2 and on the trunk, the prepare statement takes 15+ minutes. I cannot reliably reproduce this; I run the same script several times in a row and I cannot predict whether it will take 220 seconds or whether it will take 15+ minutes. I am quite motivated to work on this problem, as this is blocking me from using Derby for a project that I'm quite keen on, but I need some suggestions and ideas about how to attack it. From my perspective there are 3 primary topics: 1) Why did optimizer performance for this query degrade so significantly from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower, for this particular query at least, in 10.2. Sometimes it is 10x slower. 2) What is the source of the non-determinism? Why does the optimizer often take 4 minutes to optimize this query on the trunk, but sometimes take 15+ minutes? I don't believe that I'm changing anything from run to run. 3) Can we improve the optimizer performance even beyond what it was for 10.1.2? I realize that this is an ugly query, but I was hoping to see an optimization time of 5-10 seconds, not 90 seconds (and certainly not 220 seconds). I have attempted to start answering some of these questions, with limited success. Here is some of what I think I've discovered so far: - the optimizer changes in 10.2 seem to have given the optimizer many more choices of possible query plans to consider. I think this means that, if the optimizer does not time out, it will spend substantially more time optimizing because there are more choices to evaluate. Does this by itself mean that the optimizer will take 2.5 times longer in 10.2 than it did in 10.1? - something about this query seems to make the costing mechanism go haywire, and produce extreme costs. While stepping through the optimization of this query in the debugger I have seen it compute costs like 1e63 and 1e200. This might be very closely related to DERBY-1905, although I don't think I'm doing any subqueries here. But maybe I'm misunderstanding the term subquery in DERBY-1905. At any rate, due to the enormous estimated costs, timeout does not occur. - the WHERE clause in this query is converted during compilation to an equivalent IN clause, I believe, which then causes me to run into a number of the problems described in DERBY-47 and DERBY-713. Specifically, rather than constructing a plan which involves 4 index probes for the 4 WHERE clause values, the optimizer decides that an index scan must be performed and that it will have to process the entire index (because the query uses parameter markers, not literal values). So perhaps solving DERBY-47 would help me - the optimizer in fact comes up with a decent query plan quite quickly. I have experimented with placing a hard limit into the optimizer timeout code, so that I can force optimization to stop after an arbitrary fixed period of time. Then I have been able to set that value to as low as 1 second, and the optimizer has produced plans that then execute in a few milliseconds. Of course, I have only tried this with a trivial amount of data in my database, so it's possible that the plan produced by the optimizer after just a second of optimizing is in fact poor, and I'm just not noticing it because my data sizes are so small. At this point, what would be really helpful to me would be some suggestions about some general approaches or techniques to try to start breaking down and analyzing
[jira] [Updated] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2
[ https://issues.apache.org/jira/browse/DERBY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2130: -- Attachment: jumpReset_10_11_trunk_diff.txt I manually merged the changes to trunk (jumpReset_10_11_trunk_diff.txt) and find the query runs in 64 seconds on trunk vs the 13 on 10.1, so three times faster but nowhere near the 10.1 performance. I am using java version 1.7.0 Java(TM) SE Runtime Environment (build pwi3270sr5-20130619_01(SR5)) IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 x86-32 20130617_152572 (JIT enabled, AOT enabled) J9VM - R26_Java726_SR5_20130617_1436_B152572 JIT - r11.b04_20130528_38954ifx1 GC - R26_Java726_SR5_20130617_1436_B152572 J9CL - 20130617_152572) JCL - 20130616_01 based on Oracle 7u25-b12 I am not sure if I made an error with the merge or if there is some other regression that has been masked by this one. Optimizer performance slowdown from 10.1 to 10.2 Key: DERBY-2130 URL: https://issues.apache.org/jira/browse/DERBY-2130 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4 Reporter: Bryan Pendleton Labels: derby_triage10_11 Attachments: jumpReset_10_11_trunk_diff.txt, jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt, plans.diff, repro.sql Attached is 'repro.sql', an IJ script which demonstrates what I believe to be a serious performance issue in the Optimizer. I have run this script in a number of configurations: - 10.1.2.1: the script runs successfully. The 'prepare' statement takes about 90 seconds, on a fairly powerful Windows machine - 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777 - 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement often takes about 220 seconds, on the same Windows machine Intermittently, on 10.2 and on the trunk, the prepare statement takes 15+ minutes. I cannot reliably reproduce this; I run the same script several times in a row and I cannot predict whether it will take 220 seconds or whether it will take 15+ minutes. I am quite motivated to work on this problem, as this is blocking me from using Derby for a project that I'm quite keen on, but I need some suggestions and ideas about how to attack it. From my perspective there are 3 primary topics: 1) Why did optimizer performance for this query degrade so significantly from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower, for this particular query at least, in 10.2. Sometimes it is 10x slower. 2) What is the source of the non-determinism? Why does the optimizer often take 4 minutes to optimize this query on the trunk, but sometimes take 15+ minutes? I don't believe that I'm changing anything from run to run. 3) Can we improve the optimizer performance even beyond what it was for 10.1.2? I realize that this is an ugly query, but I was hoping to see an optimization time of 5-10 seconds, not 90 seconds (and certainly not 220 seconds). I have attempted to start answering some of these questions, with limited success. Here is some of what I think I've discovered so far: - the optimizer changes in 10.2 seem to have given the optimizer many more choices of possible query plans to consider. I think this means that, if the optimizer does not time out, it will spend substantially more time optimizing because there are more choices to evaluate. Does this by itself mean that the optimizer will take 2.5 times longer in 10.2 than it did in 10.1? - something about this query seems to make the costing mechanism go haywire, and produce extreme costs. While stepping through the optimization of this query in the debugger I have seen it compute costs like 1e63 and 1e200. This might be very closely related to DERBY-1905, although I don't think I'm doing any subqueries here. But maybe I'm misunderstanding the term subquery in DERBY-1905. At any rate, due to the enormous estimated costs, timeout does not occur. - the WHERE clause in this query is converted during compilation to an equivalent IN clause, I believe, which then causes me to run into a number of the problems described in DERBY-47 and DERBY-713. Specifically, rather than constructing a plan which involves 4 index probes for the 4 WHERE clause values, the optimizer decides that an index scan must be performed and that it will have to process the entire index (because the query uses parameter markers, not literal values). So perhaps solving DERBY-47 would help me - the optimizer in fact comes up with a decent query plan quite quickly. I have experimented with placing a hard limit into the optimizer timeout code, so that I can force optimization to stop after
[jira] [Updated] (DERBY-2813) store/ClassLoaderBootTest fixture testBootingAnAlreadyBootedDatabase fails indicating derby booted a database that was already booted by another CLR if security manager i
[ https://issues.apache.org/jira/browse/DERBY-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2813: -- Issue fix info: (was: High Value Fix) Unchecking HVF since this is just a test issue. store/ClassLoaderBootTest fixture testBootingAnAlreadyBootedDatabase fails indicating derby booted a database that was already booted by another CLR if security manager is on -- Key: DERBY-2813 URL: https://issues.apache.org/jira/browse/DERBY-2813 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.3.1.4, 10.11.0.0 Environment: The test ClassLoaderBoot test currently runs without security manager. Security manager needs to be enabled. Reporter: Kathey Marsden Labels: derby_triage10_11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DERBY-3312) Local Network Server Performance degradation with 10.2 or later
[ https://issues.apache.org/jira/browse/DERBY-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3312. --- Resolution: Won't Fix Received no objections to closing this won't fix. Locators improved performance on some operations and slowed others. Local Network Server Performance degradation with 10.2 or later --- Key: DERBY-3312 URL: https://issues.apache.org/jira/browse/DERBY-3312 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1 Environment: Intel x86 based server SuSE Linux Enterprise Server 10 Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Derby 10.3.2.1 Reporter: Timothy Graf Labels: derby_triage10_11 Attachments: LobPerf.java We have a Java based XML-RPC client/server product that incorporates an embedded Derby database and network server. Our client uses the derby JDBC ndriver and network client to connect to the Derby Network Server. We recently moved from Cloudscape, which I believe used the 10.1.3.1 Derby code, because of other issues which seem to be resolved by moving to the latest Derby release. We have a very simple database with a simple table. This table does include BLOBs, however its size has not been an issue and we limit our records to 500. Since moving to the latest release of Derby, version 10.3.2.1, we noticed that our clients running on the same machine as our server take much longer to retrieve a list of records from the database. Our clients running on a remote machine do not seem to have any performance issues when retrieving the same list of records. We start our Network Server in Java through the API so I don't think the Security Manager is the issue. I read that performance could be affected by the Security Manager, but according to the Derby documentation, The Network Server will not attempt to install a security manager if you start the server from your application using the programmatic API ... I tried going back several releases of Derby and the performance issue seems to go away when I run with version 10.1.3.1 of Derby. However we see the same issue that we saw with Cloudscape in that we can not turn off connection logging. We also had stability problems with the Network Server with Cloudscape. We would really prefer to use the latest Derby release however the performance issues are a sever limitation. I thought that maybe this was a simple Network Server configuration issue however after researching this issue I have not found anything from a configuration standpoint that may help. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-2130) Optimizer performance slowdown from 10.1 to 10.2
[ https://issues.apache.org/jira/browse/DERBY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-2130: -- Issue fix info: High Value Fix,Newcomer,Repro attached (was: High Value Fix,Repro attached) Optimizer performance slowdown from 10.1 to 10.2 Key: DERBY-2130 URL: https://issues.apache.org/jira/browse/DERBY-2130 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.1.4 Reporter: Bryan Pendleton Labels: derby_triage10_11 Attachments: jumpReset.patch, plan10_1_2_1.txt, plan10_2.txt, plans.diff, repro.sql Attached is 'repro.sql', an IJ script which demonstrates what I believe to be a serious performance issue in the Optimizer. I have run this script in a number of configurations: - 10.1.2.1: the script runs successfully. The 'prepare' statement takes about 90 seconds, on a fairly powerful Windows machine - 10.1.3.1: the script produces a NPE. I believe this is DERBY-1777 - 10.2.1.8/trunk: the script runs successfully. The 'prepare' statement often takes about 220 seconds, on the same Windows machine Intermittently, on 10.2 and on the trunk, the prepare statement takes 15+ minutes. I cannot reliably reproduce this; I run the same script several times in a row and I cannot predict whether it will take 220 seconds or whether it will take 15+ minutes. I am quite motivated to work on this problem, as this is blocking me from using Derby for a project that I'm quite keen on, but I need some suggestions and ideas about how to attack it. From my perspective there are 3 primary topics: 1) Why did optimizer performance for this query degrade so significantly from 10.1.2.1 to 10.2? The optimizer seems to be at least 2.5 times slower, for this particular query at least, in 10.2. Sometimes it is 10x slower. 2) What is the source of the non-determinism? Why does the optimizer often take 4 minutes to optimize this query on the trunk, but sometimes take 15+ minutes? I don't believe that I'm changing anything from run to run. 3) Can we improve the optimizer performance even beyond what it was for 10.1.2? I realize that this is an ugly query, but I was hoping to see an optimization time of 5-10 seconds, not 90 seconds (and certainly not 220 seconds). I have attempted to start answering some of these questions, with limited success. Here is some of what I think I've discovered so far: - the optimizer changes in 10.2 seem to have given the optimizer many more choices of possible query plans to consider. I think this means that, if the optimizer does not time out, it will spend substantially more time optimizing because there are more choices to evaluate. Does this by itself mean that the optimizer will take 2.5 times longer in 10.2 than it did in 10.1? - something about this query seems to make the costing mechanism go haywire, and produce extreme costs. While stepping through the optimization of this query in the debugger I have seen it compute costs like 1e63 and 1e200. This might be very closely related to DERBY-1905, although I don't think I'm doing any subqueries here. But maybe I'm misunderstanding the term subquery in DERBY-1905. At any rate, due to the enormous estimated costs, timeout does not occur. - the WHERE clause in this query is converted during compilation to an equivalent IN clause, I believe, which then causes me to run into a number of the problems described in DERBY-47 and DERBY-713. Specifically, rather than constructing a plan which involves 4 index probes for the 4 WHERE clause values, the optimizer decides that an index scan must be performed and that it will have to process the entire index (because the query uses parameter markers, not literal values). So perhaps solving DERBY-47 would help me - the optimizer in fact comes up with a decent query plan quite quickly. I have experimented with placing a hard limit into the optimizer timeout code, so that I can force optimization to stop after an arbitrary fixed period of time. Then I have been able to set that value to as low as 1 second, and the optimizer has produced plans that then execute in a few milliseconds. Of course, I have only tried this with a trivial amount of data in my database, so it's possible that the plan produced by the optimizer after just a second of optimizing is in fact poor, and I'm just not noticing it because my data sizes are so small. At this point, what would be really helpful to me would be some suggestions about some general approaches or techniques to try to start breaking down and analyzing this problem. -- This message was sent by Atlassian JIRA
[jira] [Commented] (DERBY-6373) NPE in Statement.getWarnings()
[ https://issues.apache.org/jira/browse/DERBY-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799116#comment-13799116 ] Kathey Marsden commented on DERBY-6373: --- I see that now. I must have made an error in my testing, but it is curious Glenn seemed to indicate some change since 10.8.2.2. Regardless, your fix looks good. Hopefully, it will fix Glenn's scenario. NPE in Statement.getWarnings() -- Key: DERBY-6373 URL: https://issues.apache.org/jira/browse/DERBY-6373 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.10.1.1 Environment: JDK 7 Reporter: Glenn McGregor Assignee: Knut Anders Hatlen Priority: Minor Attachments: d6373-1a.diff, D6373.java After executing a batch in a prepared statement, I call getWarnings() on that statement. A NPE is thrown. at org.apache.derby.client.am.SqlWarning.getSQLWarning(SqlWarning.java:117) at org.apache.derby.client.am.Statement.getWarnings(Statement.java:862) ... Addtional info: In a unit test, which worked for 10.8.2.2, a batch of 4 deletes were issued. They were expected to fail, as there were no matching rows. There was a SQLWarning chain in the statement, 4 deep, one for each row that failed with text: No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. However, each warning had 'nextException_' null. When attempting to chain on the exceptions when building the warning, a NPE is thrown. Perhaps something like changing line 105 of SqlWarning.java to if ( nextWarning_ != null nextException_ != null ) Of course perhaps there's always supposed to be a corresponding exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-532) Support deferrable constraints
[ https://issues.apache.org/jira/browse/DERBY-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799219#comment-13799219 ] Kathey Marsden commented on DERBY-532: -- I have not had an opportunity to look at the patch, but have a general question. For XA will the deferred constraints be enforced at prepare time? Support deferrable constraints -- Key: DERBY-532 URL: https://issues.apache.org/jira/browse/DERBY-532 Project: Derby Issue Type: Improvement Components: SQL Reporter: Jörg von Frantzius Assignee: Dag H. Wanvik Labels: derby_triage10_11 Attachments: deferredConstraints.html, deferredConstraints.html, derby-532-syntax-binding-dict-1.diff, derby-532-syntax-binding-dict-1.status, derby-532-syntax-binding-dict-2.diff, derby-532-syntax-binding-dict-2.status, derby-532-syntax-binding-dict-all-1.diff, derby-532-testAlterConstraintInvalidation.diff, derby-532-testAlterConstraintInvalidation.status, derby-532-unique-pk-1.diff, derby-532-unique-pk-1.status In many situations it is desirable to have constraints checking taking place only at transaction commit time, and not before. If e.g. there is a chain of foreign key constraints between tables, insert statements have to be ordered to avoid constraint violations. If foreign key references are circular, the DML has to be split into insert statements and subsequent update statements by the user. In other words, with deferred constraints checking, life is much easier for the user. Also it can create problems with softwares such as object-relational mapping tools that are not prepared for statement ordering and thus depend on deferred constraints checking. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DERBY-6382) After Inplace compress: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk caused by Caused by: java.io.EOFException: Reached end of
[ https://issues.apache.org/jira/browse/DERBY-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-6382. --- Resolution: Fixed Fix Version/s: 10.7.1.4 10.6.2.3 10.5.3.2 Assignee: Rick Hillegas backported to 10.5. Assigning to Rick since he contributed the original fix. After Inplace compress: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk caused by Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. Key: DERBY-6382 URL: https://issues.apache.org/jira/browse/DERBY-6382 Project: Derby Issue Type: Bug Affects Versions: 10.5.3.0 Reporter: Kathey Marsden Assignee: Rick Hillegas Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.9.1.0, 10.8.3.0 .The reproduction attached to DERBY-5234, DbCompressErrorTester shows the error below. 1335570 and 1335677 were committed to trunk and ported to 10.8 branch at subversion revision 1337258 and fix this issue. Unfortunately it did not fix the issue the reporting user was experiencing, so DERBY-5234 was closed CannotReproduce. Creating this issue to make sure the fixed issue is tracked separately as fixed. java DbCompressErrorTester Loading database driver iterations=00 inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Delete - done 00 rows deleted Compress inplace - done inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Inserted data: 326943 Deleted data: 0 java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2284) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1333) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1692) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309) at DbCompressErrorTester.insertData(DbCompressErrorTester.java:162) at DbCompressErrorTester.test(DbCompressErrorTester.java:116) at DbCompressErrorTester.main(DbCompressErrorTester.java:38) Caused by: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 12 more Caused by: java.sql.SQLException: Java exception: 'Reached end of file while attempting to read a whole page.: java.io.E OFException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:408) ... 10 more Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:484)
[jira] [Commented] (DERBY-1397) Tuning Guide: Puzzling optimizer documentation
[ https://issues.apache.org/jira/browse/DERBY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798014#comment-13798014 ] Kathey Marsden commented on DERBY-1397: --- I think the why would be to improve performance if hash joins are being rejected as an option when there is plenty of memory available especially as the default is very (too) low for most environments. I think the difficulty getting a crisp explanation comes from the what to set it to. Tuning Guide: Puzzling optimizer documentation -- Key: DERBY-1397 URL: https://issues.apache.org/jira/browse/DERBY-1397 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: Rick Hillegas Assignee: Kim Haase Labels: derby_triage10_5_2 Selectivity and cardinality statistics Working with cardinality statistics When cardinality statistics are automatically updated For other operations, Derby automatically updates statistics for the table and all indexes on the table if they are already exist. Those operations are: * (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. * (index only) When you drop a column that is part of a table's index; the statistics for the affected index are dropped, and statistics for the other indexes on the table are updated. What does the second bullet mean? Derby doesn't let you drop a column from a table right now. -- Here's another puzzling piece of optimizer documentation: I'm puzzled by the following paragraph in Tuning Guide-DML statements and performance-Performance and optimization-Joins and performance-Join strategies: If memory use is not a problem for your environment, set this property to a high number; allowing the optimizer the maximum flexibility in considering a join strategy queries involving large queries leads to better performance. It can also be set to smaller values for more limited environments. I can't find the name of this property on that page of the Tuning Guide. I'm also confused about what we consider to be a high number versus what we consider to be smaller values. Would appreciate advice here. Satheesh adds this: The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB. Current default value is too small, so it would be a good tip for developers to know and tune this property. It would be great if Derby can configure this property value based on factors like max heap size, size of data cache and/or other parameters. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-6373) NPE in Statement.getWarnings()
[ https://issues.apache.org/jira/browse/DERBY-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798211#comment-13798211 ] Kathey Marsden commented on DERBY-6373: --- This issue is marked as a regression and the user indicated the problem case worked with 10.8.2.2, but the repro program throws an NPE all the way back to 10.10.1.1. NPE in Statement.getWarnings() -- Key: DERBY-6373 URL: https://issues.apache.org/jira/browse/DERBY-6373 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.10.1.1 Environment: JDK 7 Reporter: Glenn McGregor Assignee: Knut Anders Hatlen Priority: Minor Attachments: d6373-1a.diff, D6373.java After executing a batch in a prepared statement, I call getWarnings() on that statement. A NPE is thrown. at org.apache.derby.client.am.SqlWarning.getSQLWarning(SqlWarning.java:117) at org.apache.derby.client.am.Statement.getWarnings(Statement.java:862) ... Addtional info: In a unit test, which worked for 10.8.2.2, a batch of 4 deletes were issued. They were expected to fail, as there were no matching rows. There was a SQLWarning chain in the statement, 4 deep, one for each row that failed with text: No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. However, each warning had 'nextException_' null. When attempting to chain on the exceptions when building the warning, a NPE is thrown. Perhaps something like changing line 105 of SqlWarning.java to if ( nextWarning_ != null nextException_ != null ) Of course perhaps there's always supposed to be a corresponding exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (DERBY-6373) NPE in Statement.getWarnings()
[ https://issues.apache.org/jira/browse/DERBY-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798211#comment-13798211 ] Kathey Marsden edited comment on DERBY-6373 at 10/17/13 7:16 PM: - This issue is marked as a regression and the user indicated the problem case worked with 10.8.2.2, but the repro program throws an NPE all the way back to 10.1.1.1 so doesn't look like a regression at least with regard to the reproduction attached. was (Author: kmarsden): This issue is marked as a regression and the user indicated the problem case worked with 10.8.2.2, but the repro program throws an NPE all the way back to 10.10.1.1. NPE in Statement.getWarnings() -- Key: DERBY-6373 URL: https://issues.apache.org/jira/browse/DERBY-6373 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.10.1.1 Environment: JDK 7 Reporter: Glenn McGregor Assignee: Knut Anders Hatlen Priority: Minor Attachments: d6373-1a.diff, D6373.java After executing a batch in a prepared statement, I call getWarnings() on that statement. A NPE is thrown. at org.apache.derby.client.am.SqlWarning.getSQLWarning(SqlWarning.java:117) at org.apache.derby.client.am.Statement.getWarnings(Statement.java:862) ... Addtional info: In a unit test, which worked for 10.8.2.2, a batch of 4 deletes were issued. They were expected to fail, as there were no matching rows. There was a SQLWarning chain in the statement, 4 deep, one for each row that failed with text: No row was found for FETCH, UPDATE or DELETE; or the result of a query is an empty table. However, each warning had 'nextException_' null. When attempting to chain on the exceptions when building the warning, a NPE is thrown. Perhaps something like changing line 105 of SqlWarning.java to if ( nextWarning_ != null nextException_ != null ) Of course perhaps there's always supposed to be a corresponding exception. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-1397) Tuning Guide: Puzzling optimizer documentation
[ https://issues.apache.org/jira/browse/DERBY-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798506#comment-13798506 ] Kathey Marsden commented on DERBY-1397: --- The only out of memory complaint I have gotten was a bug: https://issues.apache.org/jira/browse/DERBY-6096 where the user as a work around set derby.language.maxMemoryPerTable to 0 to avoid hash joins all together. The more common symptom would be one of performance where nested loop joins are chosen instead of hash joins. I haven't heard that complaint specifically, but it is nuanced because the query still works, just is not as fast as it could or should be. I am all for changing the property default to something more reasonable. I am not sure if there is an issue for that or not. I am also not sure what would be a good rule for choosing a default value that would work for both small and large memory profiles. Tuning Guide: Puzzling optimizer documentation -- Key: DERBY-1397 URL: https://issues.apache.org/jira/browse/DERBY-1397 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.2.1.6 Reporter: Rick Hillegas Assignee: Kim Haase Labels: derby_triage10_5_2 Selectivity and cardinality statistics Working with cardinality statistics When cardinality statistics are automatically updated For other operations, Derby automatically updates statistics for the table and all indexes on the table if they are already exist. Those operations are: * (all indexes) When you execute SYSCS_UTIL.SYSCS_COMPRESS_TABLE. * (index only) When you drop a column that is part of a table's index; the statistics for the affected index are dropped, and statistics for the other indexes on the table are updated. What does the second bullet mean? Derby doesn't let you drop a column from a table right now. -- Here's another puzzling piece of optimizer documentation: I'm puzzled by the following paragraph in Tuning Guide-DML statements and performance-Performance and optimization-Joins and performance-Join strategies: If memory use is not a problem for your environment, set this property to a high number; allowing the optimizer the maximum flexibility in considering a join strategy queries involving large queries leads to better performance. It can also be set to smaller values for more limited environments. I can't find the name of this property on that page of the Tuning Guide. I'm also confused about what we consider to be a high number versus what we consider to be smaller values. Would appreciate advice here. Satheesh adds this: The property it may be referring to is *derby.language.maxMemoryPerTable*. The default value is 1024 KB. Current default value is too small, so it would be a good tip for developers to know and tune this property. It would be great if Derby can configure this property value based on factors like max heap size, size of data cache and/or other parameters. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-5234) Unable to insert data into table. Failed due be ERROR XSDG0: Page Page(51919,Container(0, 1104)) could not be read from disk.
[ https://issues.apache.org/jira/browse/DERBY-5234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798572#comment-13798572 ] Kathey Marsden commented on DERBY-5234: --- So, although it was closed CannotReproduce, I think *something* was fixed in this issue. 1335570 and 1335677 were committed to trunk and ported to 10.8 branch at subversion revision 1337258. For bookkeeping and possible further backport it would seem to make sense to open a separate issue for what was fixed. Unable to insert data into table. Failed due be ERROR XSDG0: Page Page(51919,Container(0, 1104)) could not be read from disk. --- Key: DERBY-5234 URL: https://issues.apache.org/jira/browse/DERBY-5234 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.5.3.0 Environment: HP-UX 11iv2 in production environment with JDK1.6; Solaris 5/10 in test environment with JDK 1.6 Reporter: Varma R Priority: Critical Labels: ERROR, XSDG0, apache, corruption, data, derby, derby_triage10_10, derby_triage10_9 Attachments: 5234_alloc.out, 5234_page_10219.out, 5234_summary.out, DataFileReader_Output.zip, DbCompressErrorTester.java, derby-5234-01-aa-emptyAllocPage.diff, derby-5234-01-ab-emptyAllocPage.diff, derby-5234-02-aa-edgeCaseTests.diff, Derby5234.java, Derby5234.java, log191.dat, log85.dat One of the derby database table gets corrupted/indicates connection not available during processing inserts from java client application as shown in the trace and the only way to recover from this error is to rebuild the DB - by deleting the data and creating the tables again. This happens once in a while (thrice in a span of two months) and the java application (run in multiple servers), which updates the database, processes around 100 million transactions per hour (in total and each transation results in 4-5 updates to the DB) There are eight tables in the derby database. TABLE NAME ROWS COUNT (at time of corruption) - KPI.KPI_MERGEIN; 362917 KPI.KPI_IN; 422508 KPI.KPI_DROPPED;53667 KPI.KPI_ERROR1; 0 KPI.KPI_ERROR2; 2686 KPI.KPI_ERRORMERGE;0 KPI.KPI_MERGEOUT; 362669 KPI.KPI_OUT; 125873 The derby database has been started with the following parameters CMD=java -Dderby.system.home=$DERBY_OPTS -Dderby.locks.monitor=true -Dderby.locks.deadlockTrace=true -Dderby.locks.escalationThreshold=5 -Dderby.locks.waitTimeout= -1 -Dderby.storage.pageCacheSize=10 -Xms512M -Xmx3072M -XX:NewSize=256M -classpath $DERBY_CLASSPATH org.apache.derby.drda.NetworkServerControl start -h $KPIDERBYHOST -p $DERBY_KPI_PORT The corrupted database tar (filesystem) in live environment was moved to a test system (Solaris system) and few checks were run on the corrupted DB as part of analysis (DB does start fine) While trying to insert a row in any table expect KPI.KPI_MERGEIN, it is successful. But when a new row is inserted into KPI.KPI_MERGEIN table using command line tool it's throwing below error message (the same message that appeared in live ij INSERT INTO KPI.KPI_MERGEIN (A0_TXN_ID, A1_NE_ID, A2_CHU_IP_ADDR, A3_BATCH_DATE,A5_CODE) VALUES (-1, 'BMTDE', '192.2.1.3', 231456879, 'KSD'); ERROR 08006: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message and in derby.log file it shows below error stacktrace. ERROR XSDG0: Page Page(51919,Container(0, 1104)) could not be read from disk. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(Unknown Source) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source) at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(Unknown Source) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(Unknown Source) at org.apache.derby.impl.store.access.heap.HeapController.doInsert(Unknown Source) at
[jira] [Updated] (DERBY-6382) After Inplace compress: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk caused by Caused by: java.io.EOFException: Reached end of f
[ https://issues.apache.org/jira/browse/DERBY-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6382: -- Description: .The reproduction attached to DERBY-5234, DbCompressErrorTester shows the error below. 1335570 and 1335677 were committed to trunk and ported to 10.8 branch at subversion revision 1337258 and fix this issue. Unfortunately it did not fix the issue the reporting user was experiencing, so DERBY-5234. Opening this issue to make sure the fixed issue is tracked separately as fixed. java DbCompressErrorTester Loading database driver iterations=00 inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Delete - done 00 rows deleted Compress inplace - done inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Inserted data: 326943 Deleted data: 0 java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2284) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1333) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1692) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309) at DbCompressErrorTester.insertData(DbCompressErrorTester.java:162) at DbCompressErrorTester.test(DbCompressErrorTester.java:116) at DbCompressErrorTester.main(DbCompressErrorTester.java:38) Caused by: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 12 more Caused by: java.sql.SQLException: Java exception: 'Reached end of file while attempting to read a whole page.: java.io.E OFException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:408) ... 10 more Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:484) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:244) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:214) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:671) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java:2342) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java:1825) at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(BaseContainer.java:314) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(BaseContainerHandle.java:183) at org.apache.derby.impl.store.access.heap.HeapController.doInsert(HeapController.java:302) at org.apache.derby.impl.store.access.heap.HeapController.insert(HeapController.java:575) at
[jira] [Created] (DERBY-6382) After Inplace compress: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk caused by Caused by: java.io.EOFException: Reached end of f
Kathey Marsden created DERBY-6382: - Summary: After Inplace compress: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk caused by Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. Key: DERBY-6382 URL: https://issues.apache.org/jira/browse/DERBY-6382 Project: Derby Issue Type: Bug Affects Versions: 10.5.3.0 Reporter: Kathey Marsden Fix For: 10.9.1.0, 10.8.3.0 The reproduction attached to DERBY-5234, DbCompressErrorTester shows the error below. 1335570 and 1335677 were committed to trunk and ported to 10.8 branch at subversion revision 1337258 and fix this issue. Unfortunately it did not fix the issue the reporting user was experiencing, so DERBY-5234. Opening this issue to make sure the fixed issue is tracked separately as fixed. java DbCompressErrorTester Loading database driver iterations=00 inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Delete - done 00 rows deleted Compress inplace - done inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Inserted data: 326943 Deleted data: 0 java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2284) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1333) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1692) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309) at DbCompressErrorTester.insertData(DbCompressErrorTester.java:162) at DbCompressErrorTester.test(DbCompressErrorTester.java:116) at DbCompressErrorTester.main(DbCompressErrorTester.java:38) Caused by: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 12 more Caused by: java.sql.SQLException: Java exception: 'Reached end of file while attempting to read a whole page.: java.io.E OFException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:408) ... 10 more Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:484) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:244) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:214) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:671) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java:2342) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java:1825) at
[jira] [Updated] (DERBY-6382) After Inplace compress: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk caused by Caused by: java.io.EOFException: Reached end of f
[ https://issues.apache.org/jira/browse/DERBY-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6382: -- Description: .The reproduction attached to DERBY-5234, DbCompressErrorTester shows the error below. 1335570 and 1335677 were committed to trunk and ported to 10.8 branch at subversion revision 1337258 and fix this issue. Unfortunately it did not fix the issue the reporting user was experiencing, so DERBY-5234 was closed CannotReproduce. Creating this issue to make sure the fixed issue is tracked separately as fixed. java DbCompressErrorTester Loading database driver iterations=00 inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Delete - done 00 rows deleted Compress inplace - done inserted: 0/00 inserted: 0/00 inserted: 0/00 inserted: 133320/00 inserted: 166650/00 inserted: 199980/00 inserted: 233310/00 inserted: 266640/00 inserted: 299970/00 Inserted data: 326943 Deleted data: 0 java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.seeNextException(Util.java:278) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:348) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2284) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1333) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1692) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309) at DbCompressErrorTester.insertData(DbCompressErrorTester.java:162) at DbCompressErrorTester.test(DbCompressErrorTester.java:116) at DbCompressErrorTester.main(DbCompressErrorTester.java:38) Caused by: java.sql.SQLException: Page Page(10219,Container(0, 1136)) could not be read from disk. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) ... 12 more Caused by: java.sql.SQLException: Java exception: 'Reached end of file while attempting to read a whole page.: java.io.E OFException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:11 9) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:408) ... 10 more Caused by: java.io.EOFException: Reached end of file while attempting to read a whole page. at org.apache.derby.impl.store.raw.data.RAFContainer4.readFull(RAFContainer4.java:484) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage0(RAFContainer4.java:244) at org.apache.derby.impl.store.raw.data.RAFContainer4.readPage(RAFContainer4.java:214) at org.apache.derby.impl.store.raw.data.CachedPage.readPage(CachedPage.java:671) at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(CachedPage.java:190) at org.apache.derby.impl.services.cache.ConcurrentCache.find(ConcurrentCache.java:295) at org.apache.derby.impl.store.raw.data.FileContainer.initPage(FileContainer.java:2342) at org.apache.derby.impl.store.raw.data.FileContainer.newPage(FileContainer.java:1825) at org.apache.derby.impl.store.raw.data.BaseContainer.addPage(BaseContainer.java:314) at org.apache.derby.impl.store.raw.data.BaseContainerHandle.addPage(BaseContainerHandle.java:183) at org.apache.derby.impl.store.access.heap.HeapController.doInsert(HeapController.java:302) at
[jira] [Commented] (DERBY-6352) Access denied (java.lang.RuntimePermission modifyThread) in store.RecoveryAfterBackup test
[
https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795263#comment-13795263
]
Kathey Marsden commented on DERBY-6352:
---
I think that it is a problem though that we are seeing the access denied error
in this context. Possibly a java Problem? I think the issue should be
reopened until we know and then closed invalid once confirmed and as a java
problem. I think that is how we have handled jvm issues in the past.
Access denied (java.lang.RuntimePermission modifyThread) in
store.RecoveryAfterBackup test
--
Key: DERBY-6352
URL: https://issues.apache.org/jira/browse/DERBY-6352
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.10.1.1
Environment: IBM java 7 Derby version 10.10.1.2 - (1494414)
Reporter: Kathey Marsden
Attachments: DERBY-6352_trunk2.diff, DERBY-6352_trunk.diff
I got a report of the following intermittent (6/60) exception in
store.RecoveryAfterBackupTest.
Exception in thread main java.security.AccessControlException: Access
denied (java.lang.RuntimePermission modifyThread)
at
java.security.AccessController.throwACE(AccessController.java:100)
at
java.security.AccessController.checkPermission(AccessController.java:174)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
at java.lang.Thread.checkAccess(Thread.java:459)
at java.lang.Thread.interrupt(Thread.java:588)
at
org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
at
java.security.AccessController.doPrivileged(AccessController.java:274)
at
org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
Source)
at
org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown
Source)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:233)
at
org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at
org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
modifyThread is a necessary permission if interrupting a thread other than
the current thread but is not in our policy file for derby.jar.
The relevant code in ContextService is:
for (ContextManager cm : allContexts) {
Thread active = cm.activeThread;
if (active == me)
continue;
if (active == null)
continue;
final Thread fActive = active;
if (cm.setInterrupted(c))
{
AccessController.doPrivileged(
new PrivilegedActionVoid() {
public Void run() {
fActive.interrupt();
return null;
}
});
}
I am not sure why this has never come up before. Are we expecting in this
context that fActive is the current thread?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (DERBY-6355) Data Integrity guidelines should include not deleting or otherwise tampering with files under the database directory
[ https://issues.apache.org/jira/browse/DERBY-6355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790530#comment-13790530 ] Kathey Marsden commented on DERBY-6355: --- Looks good. Thanks Kim! Data Integrity guidelines should include not deleting or otherwise tampering with files under the database directory Key: DERBY-6355 URL: https://issues.apache.org/jira/browse/DERBY-6355 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Assignee: Kim Haase Attachments: cadmindbintegrity.html, cadmindbintegrity.html, DERBY-6355-2.diff, DERBY-6355.diff The page for maintaining data integrity: https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/adminguide/cadmindbintegrity.html should also warn against touching any files under the database directory. Maybe we could paraphrase from the README. file: # * # *** DO NOT TOUCH FILES IN THIS DIRECTORY!*** # *** FILES IN THIS DIRECTORY AND SUBDIRECTORIES CONSTITUTE A DERBY *** # *** DATABASE, WHICH INCLUDES THE DATA (USER AND SYSTEM) AND THE *** # *** FILES NECESSARY FOR DATABASE RECOVERY.*** # *** EDITING, ADDING, OR DELETING ANY OF THESE FILES MAY CAUSE DATA*** # *** CORRUPTION AND LEAVE THE DATABASE IN A NON-RECOVERABLE STATE. *** # */ -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[ https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-5610. --- Resolution: Fixed Fix Version/s: (was: 10.9.2.2) (was: 10.8.3.1) Resolved in trunk with revision 1526172, in 10.10 with revision 1526486. ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes -- Key: DERBY-5610 URL: https://issues.apache.org/jira/browse/DERBY-5610 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.3.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Labels: derby_triage10_9 Fix For: 10.10.1.3, 10.11.0.0 Attachments: derby-5610_2_diff.txt, derby-5610_diff.txt, derby-5610_trunkdiff.txt ServerPropertiesTest showed the below output when running. The ping retries and the test passes. I am not sure if in fact a Connection reset is a valid response if the server is not fully up and the test is just being too verbose or if it is real problem that we get this Error. .java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source) at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) java.net.SocketException: Connection reset at
[jira] [Resolved] (DERBY-3624) testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing
[ https://issues.apache.org/jira/browse/DERBY-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-3624. --- Resolution: Fixed Fix Version/s: 10.11.0.0 10.10.1.3 Issue fix info: (was: Patch Available) testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing --- Key: DERBY-3624 URL: https://issues.apache.org/jira/browse/DERBY-3624 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.1.3, 10.8.3.1, 10.10.1.3, 10.11.0.0 Environment: iseries, ibm 1.5.: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Classic VM (build 1.5, build JDK-1.5, native threads, jitc_de) Reporter: Myrna van Lunteren Assignee: Kathey Marsden Labels: derby_triage10_8 Fix For: 10.10.1.3, 10.11.0.0 Attachments: derby-3624_diff.txt, derby.log, st_derby715.tmp I saw this fail once; a couple of reruns didn't duplicate the problem. The only difference appears to be that one of the deadlock messages is missing from the output. 4 del Got a Deadlock. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-6350) Provide a rolling file implementation of derby.log
[ https://issues.apache.org/jira/browse/DERBY-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6350: -- Assignee: Brett Bergquist Provide a rolling file implementation of derby.log -- Key: DERBY-6350 URL: https://issues.apache.org/jira/browse/DERBY-6350 Project: Derby Issue Type: Improvement Components: Miscellaneous Reporter: Brett Bergquist Assignee: Brett Bergquist Priority: Minor Labels: features Attachments: rollingfilelog.patch.txt, rollingfilelog.patch.txt, rolling_file_patch_5.txt, rolling_file_patch_6.txt By default, derby.log grows without bounds if the derby.infolog.append property is set to true. Setting this to true helps in a hands off production environment to ensure that if Derby restarts, the derby.log which might contain important information is not lost. On the other hand, when set the true the derby.log grows without bounds. This is problematic in a long running system. What is really needed is the ability to have a rolling derby.log file support where the maximum file size and maximum number of files can be specified. Derby has the ability to configure the location of the log file (ie. derby.stream.error.file) and also two methods of redirecting the error stream (.ie derby.stream.error.method and derby.stream.error.field). There is no standard implementation that supports a rolling derby.log however. This facility should be part of the core Derby system so that it works in both embedded and network server models. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-3624) testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing
[ https://issues.apache.org/jira/browse/DERBY-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3624: -- Attachment: derby-3624_diff.txt This looks like a timing issue with the test which relies on sleeps to synchronize the two threads. I can reliably lose deadlocks if I put a sleep at the beginning of t2.run(). Attaching a patch which waits for locks to be taken rather than using the sleep to synchronize. Even if I put a sleep in at the beginning of t2.run() the test passes with this patch. testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing --- Key: DERBY-3624 URL: https://issues.apache.org/jira/browse/DERBY-3624 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.1.3, 10.8.3.1, 10.10.1.3, 10.11.0.0 Environment: iseries, ibm 1.5.: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Classic VM (build 1.5, build JDK-1.5, native threads, jitc_de) Reporter: Myrna van Lunteren Labels: derby_triage10_8 Attachments: derby-3624_diff.txt, derby.log, st_derby715.tmp I saw this fail once; a couple of reruns didn't duplicate the problem. The only difference appears to be that one of the deadlock messages is missing from the output. 4 del Got a Deadlock. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (DERBY-3624) testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing
[ https://issues.apache.org/jira/browse/DERBY-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-3624: -- Issue fix info: Patch Available testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing --- Key: DERBY-3624 URL: https://issues.apache.org/jira/browse/DERBY-3624 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.1.3, 10.8.3.1, 10.10.1.3, 10.11.0.0 Environment: iseries, ibm 1.5.: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Classic VM (build 1.5, build JDK-1.5, native threads, jitc_de) Reporter: Myrna van Lunteren Assignee: Kathey Marsden Labels: derby_triage10_8 Attachments: derby-3624_diff.txt, derby.log, st_derby715.tmp I saw this fail once; a couple of reruns didn't duplicate the problem. The only difference appears to be that one of the deadlock messages is missing from the output. 4 del Got a Deadlock. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (DERBY-3624) testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing
[ https://issues.apache.org/jira/browse/DERBY-3624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-3624: - Assignee: Kathey Marsden testfailure in storetests/st_derby715 with ibm 1.5 on iseries machine; one deadlock message missing --- Key: DERBY-3624 URL: https://issues.apache.org/jira/browse/DERBY-3624 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.4.1.3, 10.8.3.1, 10.10.1.3, 10.11.0.0 Environment: iseries, ibm 1.5.: java version 1.5.0 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05) Classic VM (build 1.5, build JDK-1.5, native threads, jitc_de) Reporter: Myrna van Lunteren Assignee: Kathey Marsden Labels: derby_triage10_8 Attachments: derby-3624_diff.txt, derby.log, st_derby715.tmp I saw this fail once; a couple of reruns didn't duplicate the problem. The only difference appears to be that one of the deadlock messages is missing from the output. 4 del Got a Deadlock. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-973) Restore fails in OnlineBackupTest1
[ https://issues.apache.org/jira/browse/DERBY-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13784384#comment-13784384 ] Kathey Marsden commented on DERBY-973: -- Yuskel, do you consistently get an EOF when backup with 10.5? It may not be this issue but rather some corruption that is not detected with consistency check. Are you able to compress all the tables in the database? See http://wiki.apache.org/db-derby/DatabaseConsistencyCheck for a program that can do this. I am perplexed about how 10.10 could complete but be missing data. Restore fails in OnlineBackupTest1 -- Key: DERBY-973 URL: https://issues.apache.org/jira/browse/DERBY-973 Project: Derby Issue Type: Bug Components: Store, Test Affects Versions: 10.2.1.6 Environment: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 Reporter: Ole Solberg Labels: derby_triage10_8 Attachments: 377370.zip, d973.zip, derby.log, derby.log Signature: * Diff file storeall/storemore/OnlineBackupTest1.diff *** Start: OnlineBackupTest1 jdk1.5.0_04 storeall:storemore 2006-02-13 16:17:08 *** 6 del Restored From the Backup 7 del Consistency Check is Done 8 del database shutdown properly 9 del End Online Backup Test1 9 add ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XSDG0: Page Page(1,Container(0, 14929)) could not be read from disk. SQL Exception: Failed to start database 'wombat', see the next exception for details. Test Failed. *** End: OnlineBackupTest1 jdk1.5.0_04 storeall:storemore 2006-02-13 16:18:08 *** -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (DERBY-6248) nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408
[ https://issues.apache.org/jira/browse/DERBY-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780167#comment-13780167 ] Kathey Marsden commented on DERBY-6248: --- I ran fifty times and did not see this failure on my Windows machine. In the derby.log there are quite a few messages: The XA transaction timed out and is going to be rolled back. The transaction Xid is (4660,7c00,6400).^M but I don't see any exceptions in the log. From the stack trace it would seem that we are trying to do an autocommit on connection close and that autocommit fails. It could be that we are indeed getting that exception but it is not getting logged. I am guessing that if I put the rollback before the close() we might eliminate the intermittent failure but that might be just masking a bug. Things I don't understand .. - Why are we doing an autocommit on connection.close()? - As we do commit, what is the actual exception on commit? Are the transaction timeout's relevant or is something else going on. - Why does SYNCCTL not handle the exception on commit properly and the give the DDM error? - Why is the failure intermittent? Will attach the derby.log and error-stackttrace.out. nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. --- Key: DERBY-6248 URL: https://issues.apache.org/jira/browse/DERBY-6248 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Reporter: Mike Matrigali intermittent nightly regression test failure in trunk, linux, ibm16 only happened once in may on this machine environment. http://people.apache.org/~myrnavl/derby_test_results/main/linux/testlog/ibm16/1488444-suites.All_diff.txt There was 1 error: 1) testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.LogicalConnection.close(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testDerby966(XATest.java:1079) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: org.apache.derby.client.am.DisconnectException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseSYNCCTLError(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.parseSYNCCTLreply(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.readLocalXACommit(Unknown Source) at
[jira] [Updated] (DERBY-6248) nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 i
[ https://issues.apache.org/jira/browse/DERBY-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6248: -- Attachment: error-stacktrace.out derby.log derby.log and error-stacktrace.out from an instance of the failure. nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. --- Key: DERBY-6248 URL: https://issues.apache.org/jira/browse/DERBY-6248 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Reporter: Mike Matrigali Attachments: derby.log, error-stacktrace.out intermittent nightly regression test failure in trunk, linux, ibm16 only happened once in may on this machine environment. http://people.apache.org/~myrnavl/derby_test_results/main/linux/testlog/ibm16/1488444-suites.All_diff.txt There was 1 error: 1) testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.LogicalConnection.close(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testDerby966(XATest.java:1079) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: org.apache.derby.client.am.DisconnectException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseSYNCCTLError(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.parseSYNCCTLreply(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.readLocalXACommit(Unknown Source) at org.apache.derby.client.net.NetXAConnection.readLocalXACommit_(Unknown Source) at org.apache.derby.client.net.NetXAConnection.readCommit(Unknown Source) at org.apache.derby.client.net.NetConnection.readXACommit_(Unknown Source) at org.apache.derby.client.am.ClientConnection.readCommit(Unknown Source) at org.apache.derby.client.am.ClientConnection.readAutoCommit(Unknown Source) at org.apache.derby.client.am.ClientConnection.flowClose(Unknown Source) at org.apache.derby.client.am.ClientConnection.closeForReuse(Unknown Source) ... 49 more FAILURES!!! Tests run: 17341, Failures: 0, Errors: 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (DERBY-6248) nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0
[ https://issues.apache.org/jira/browse/DERBY-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780167#comment-13780167 ] Kathey Marsden edited comment on DERBY-6248 at 9/27/13 6:22 PM: I ran fifty times and did not see this failure on my Windows machine. In the derby.log there are quite a few messages: The XA transaction timed out and is going to be rolled back. The transaction Xid is (4660,7c00,6400).^M but I don't see any exceptions in the log. From the stack trace it would seem that we are trying to do an autocommit on connection close and that autocommit fails. It could be that we are indeed getting that exception but it is not getting logged. I am guessing that if I put the rollback before the close() we might eliminate the intermittent failure but that might be just masking a bug. Things I don't understand .. - What is the actual exception on commit? Are the transaction timeout's relevant or is something else going on. - Why does SYNCCTL not handle the exception on commit properly and the give the DDM error? - Why is the failure intermittent? Will attach the derby.log and error-stackttrace.out. was (Author: kmarsden): I ran fifty times and did not see this failure on my Windows machine. In the derby.log there are quite a few messages: The XA transaction timed out and is going to be rolled back. The transaction Xid is (4660,7c00,6400).^M but I don't see any exceptions in the log. From the stack trace it would seem that we are trying to do an autocommit on connection close and that autocommit fails. It could be that we are indeed getting that exception but it is not getting logged. I am guessing that if I put the rollback before the close() we might eliminate the intermittent failure but that might be just masking a bug. Things I don't understand .. - Why are we doing an autocommit on connection.close()? - As we do commit, what is the actual exception on commit? Are the transaction timeout's relevant or is something else going on. - Why does SYNCCTL not handle the exception on commit properly and the give the DDM error? - Why is the failure intermittent? Will attach the derby.log and error-stackttrace.out. nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. --- Key: DERBY-6248 URL: https://issues.apache.org/jira/browse/DERBY-6248 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Reporter: Mike Matrigali Attachments: derby.log, error-stacktrace.out intermittent nightly regression test failure in trunk, linux, ibm16 only happened once in may on this machine environment. http://people.apache.org/~myrnavl/derby_test_results/main/linux/testlog/ibm16/1488444-suites.All_diff.txt There was 1 error: 1) testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.LogicalConnection.close(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testDerby966(XATest.java:1079) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at
[jira] [Commented] (DERBY-6248) nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408
[ https://issues.apache.org/jira/browse/DERBY-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780497#comment-13780497 ] Kathey Marsden commented on DERBY-6248: --- I think I will work on trying to get a reproduction for the case where commit fails for a local commit on an XAConnection, file a bug for that and then change this test case to rollback the connection before it closes to remove the noise from the test. Can anyone think of a good test case where we expect and can force commit to fail. Deferrable constraints will be a good one but I think not enough is implemented yet. nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. --- Key: DERBY-6248 URL: https://issues.apache.org/jira/browse/DERBY-6248 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Reporter: Mike Matrigali Attachments: derby.log, error-stacktrace.out intermittent nightly regression test failure in trunk, linux, ibm16 only happened once in may on this machine environment. http://people.apache.org/~myrnavl/derby_test_results/main/linux/testlog/ibm16/1488444-suites.All_diff.txt There was 1 error: 1) testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.LogicalConnection.close(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testDerby966(XATest.java:1079) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: org.apache.derby.client.am.DisconnectException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseSYNCCTLError(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.parseSYNCCTLreply(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.readLocalXACommit(Unknown Source) at org.apache.derby.client.net.NetXAConnection.readLocalXACommit_(Unknown Source) at org.apache.derby.client.net.NetXAConnection.readCommit(Unknown Source) at org.apache.derby.client.net.NetConnection.readXACommit_(Unknown Source) at org.apache.derby.client.am.ClientConnection.readCommit(Unknown Source) at org.apache.derby.client.am.ClientConnection.readAutoCommit(Unknown Source) at org.apache.derby.client.am.ClientConnection.flowClose(Unknown Source) at org.apache.derby.client.am.ClientConnection.closeForReuse(Unknown Source) ... 49 more
[jira] [Comment Edited] (DERBY-6248) nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0
[ https://issues.apache.org/jira/browse/DERBY-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780497#comment-13780497 ] Kathey Marsden edited comment on DERBY-6248 at 9/27/13 10:24 PM: - I think I will work on trying to get a reproduction for the case where we get a protocol error when commit fails for a local commit on an XAConnection, file a bug for that and then change this test case to rollback the connection before it closes to remove the noise from the test. Can anyone think of a good test case where we expect and can force commit to fail. Deferrable constraints will be a good one but I think not enough is implemented yet. was (Author: kmarsden): I think I will work on trying to get a reproduction for the case where commit fails for a local commit on an XAConnection, file a bug for that and then change this test case to rollback the connection before it closes to remove the noise from the test. Can anyone think of a good test case where we expect and can force commit to fail. Deferrable constraints will be a good one but I think not enough is implemented yet. nightly regression test failure: testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. --- Key: DERBY-6248 URL: https://issues.apache.org/jira/browse/DERBY-6248 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.11.0.0 Reporter: Mike Matrigali Attachments: derby.log, error-stacktrace.out intermittent nightly regression test failure in trunk, linux, ibm16 only happened once in may on this machine environment. http://people.apache.org/~myrnavl/derby_test_results/main/linux/testlog/ibm16/1488444-suites.All_diff.txt There was 1 error: 1) testDerby966(org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest)java.sql.SQLFeatureNotSupportedException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.LogicalConnection.close(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.XATest.testDerby966(XATest.java:1079) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: org.apache.derby.client.am.DisconnectException: The DDM object 0x2408 is not supported. The connection has been terminated. at org.apache.derby.client.net.NetConnectionReply.doObjnsprmSemantics(Unknown Source) at org.apache.derby.client.net.NetConnectionReply.parseSYNCCTLError(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.parseSYNCCTLreply(Unknown Source) at org.apache.derby.client.net.NetXAConnectionReply.readLocalXACommit(Unknown Source) at
[jira] [Assigned] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFail
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden reassigned DERBY-6146: - Assignee: Kathey Marsden nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali Assignee: Kathey Marsden http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFaile
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6146: -- Attachment: derby-6146_diff.txt I found that indeed if I commented out the sleep that the test failed as described in this issue. I changed the wait to wait for two rows to appear in the lock table which is what we see when the test passes. Please review. nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali Assignee: Kathey Marsden Attachments: derby-6146_diff.txt http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFaile
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6146: -- Issue fix info: Patch Available nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali Assignee: Kathey Marsden Attachments: derby-6146_diff.txt http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFaile
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6146: -- Attachment: (was: derby-6146_diff.txt) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali Assignee: Kathey Marsden http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFaile
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-6146: -- Attachment: derby-6146_diff.txt nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali Assignee: Kathey Marsden Attachments: derby-6146_diff.txt http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6123) Optional tools documentation in the reference guide should mention that optional tools require derbytools.jar be in the CLASSPATH
[ https://issues.apache.org/jira/browse/DERBY-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13778999#comment-13778999 ] Kathey Marsden commented on DERBY-6123: --- Thanks Kim, the changes look good to me. Optional tools documentation in the reference guide should mention that optional tools require derbytools.jar be in the CLASSPATH - Key: DERBY-6123 URL: https://issues.apache.org/jira/browse/DERBY-6123 Project: Derby Issue Type: Bug Components: Documentation, Tools Affects Versions: 10.10.1.1 Reporter: Kathey Marsden Assignee: Kim Haase Priority: Trivial Labels: derby_triage10_11 Attachments: DERBY-6123.diff, DERBY-6123.stat, DERBY-6123.zip The optional tools require derbytools.jar to run. This should be mentioned in the reference manual documentation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-6355) Data Integrity guidelines should include not deleting or otherwise tampering with files under the database directory
Kathey Marsden created DERBY-6355: - Summary: Data Integrity guidelines should include not deleting or otherwise tampering with files under the database directory Key: DERBY-6355 URL: https://issues.apache.org/jira/browse/DERBY-6355 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.10.1.1 Reporter: Kathey Marsden The page for maintaining data integrity: https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/adminguide/cadmindbintegrity.html should also warn against touching any files under the database directory. Maybe we could paraphrase from the README. file: # * # *** DO NOT TOUCH FILES IN THIS DIRECTORY!*** # *** FILES IN THIS DIRECTORY AND SUBDIRECTORIES CONSTITUTE A DERBY *** # *** DATABASE, WHICH INCLUDES THE DATA (USER AND SYSTEM) AND THE *** # *** FILES NECESSARY FOR DATABASE RECOVERY.*** # *** EDITING, ADDING, OR DELETING ANY OF THESE FILES MAY CAUSE DATA*** # *** CORRUPTION AND LEAVE THE DATABASE IN A NON-RECOVERABLE STATE. *** # */ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFail
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-6146. --- Resolution: Fixed Fix Version/s: 10.11.0.0 10.10.1.3 nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali Assignee: Kathey Marsden Fix For: 10.10.1.3, 10.11.0.0 Attachments: derby-6146_diff.txt http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-6352) Access denied (java.lang.RuntimePermission modifyThread) in store.RecoveryAfterBackup test
Kathey Marsden created DERBY-6352:
-
Summary: Access denied (java.lang.RuntimePermission
modifyThread) in store.RecoveryAfterBackup test
Key: DERBY-6352
URL: https://issues.apache.org/jira/browse/DERBY-6352
Project: Derby
Issue Type: Bug
Components: Test
Environment: IBM java 7
Reporter: Kathey Marsden
I got a report of the following intermittent (6/60) exception in
store.RecoveryAfterBackupTest.
Exception in thread main java.security.AccessControlException: Access denied
(java.lang.RuntimePermission modifyThread)
at
java.security.AccessController.throwACE(AccessController.java:100)
at
java.security.AccessController.checkPermission(AccessController.java:174)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
at java.lang.Thread.checkAccess(Thread.java:459)
at java.lang.Thread.interrupt(Thread.java:588)
at
org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
at
java.security.AccessController.doPrivileged(AccessController.java:274)
at
org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
Source)
at
org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown
Source)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:233)
at
org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at
org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
modifyThread is a necessary permission if interrupting a thread other than the
current thread but is not in our policy file for derby.jar.
The relevant code in ContextService is:
for (ContextManager cm : allContexts) {
Thread active = cm.activeThread;
if (active == me)
continue;
if (active == null)
continue;
final Thread fActive = active;
if (cm.setInterrupted(c))
{
AccessController.doPrivileged(
new PrivilegedActionVoid() {
public Void run() {
fActive.interrupt();
return null;
}
});
}
I am not sure why this has never come up before. Are we expecting in this
context that fActive is the current thread?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-6352) Access denied (java.lang.RuntimePermission modifyThread) in store.RecoveryAfterBackup test
[
https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-6352:
--
Affects Version/s: 10.10.1.1
Access denied (java.lang.RuntimePermission modifyThread) in
store.RecoveryAfterBackup test
--
Key: DERBY-6352
URL: https://issues.apache.org/jira/browse/DERBY-6352
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.10.1.1
Environment: IBM java 7 Derby version 10.10.1.2 - (1494414)
Reporter: Kathey Marsden
I got a report of the following intermittent (6/60) exception in
store.RecoveryAfterBackupTest.
Exception in thread main java.security.AccessControlException: Access
denied (java.lang.RuntimePermission modifyThread)
at
java.security.AccessController.throwACE(AccessController.java:100)
at
java.security.AccessController.checkPermission(AccessController.java:174)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
at java.lang.Thread.checkAccess(Thread.java:459)
at java.lang.Thread.interrupt(Thread.java:588)
at
org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
at
java.security.AccessController.doPrivileged(AccessController.java:274)
at
org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
Source)
at
org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown
Source)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:233)
at
org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at
org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
modifyThread is a necessary permission if interrupting a thread other than
the current thread but is not in our policy file for derby.jar.
The relevant code in ContextService is:
for (ContextManager cm : allContexts) {
Thread active = cm.activeThread;
if (active == me)
continue;
if (active == null)
continue;
final Thread fActive = active;
if (cm.setInterrupted(c))
{
AccessController.doPrivileged(
new PrivilegedActionVoid() {
public Void run() {
fActive.interrupt();
return null;
}
});
}
I am not sure why this has never come up before. Are we expecting in this
context that fActive is the current thread?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-6352) Access denied (java.lang.RuntimePermission modifyThread) in store.RecoveryAfterBackup test
[
https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-6352:
--
Environment: IBM java 7 Derby version 10.10.1.2 - (1494414) (was: IBM java
7)
Access denied (java.lang.RuntimePermission modifyThread) in
store.RecoveryAfterBackup test
--
Key: DERBY-6352
URL: https://issues.apache.org/jira/browse/DERBY-6352
Project: Derby
Issue Type: Bug
Components: Test
Environment: IBM java 7 Derby version 10.10.1.2 - (1494414)
Reporter: Kathey Marsden
I got a report of the following intermittent (6/60) exception in
store.RecoveryAfterBackupTest.
Exception in thread main java.security.AccessControlException: Access
denied (java.lang.RuntimePermission modifyThread)
at
java.security.AccessController.throwACE(AccessController.java:100)
at
java.security.AccessController.checkPermission(AccessController.java:174)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at
java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
at java.lang.Thread.checkAccess(Thread.java:459)
at java.lang.Thread.interrupt(Thread.java:588)
at
org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
at
java.security.AccessController.doPrivileged(AccessController.java:274)
at
org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
Source)
at
org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown
Source)
at java.sql.DriverManager.getConnection(DriverManager.java:571)
at java.sql.DriverManager.getConnection(DriverManager.java:233)
at
org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
at
org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
modifyThread is a necessary permission if interrupting a thread other than
the current thread but is not in our policy file for derby.jar.
The relevant code in ContextService is:
for (ContextManager cm : allContexts) {
Thread active = cm.activeThread;
if (active == me)
continue;
if (active == null)
continue;
final Thread fActive = active;
if (cm.setInterrupted(c))
{
AccessController.doPrivileged(
new PrivilegedActionVoid() {
public Void run() {
fActive.interrupt();
return null;
}
});
}
I am not sure why this has never come up before. Are we expecting in this
context that fActive is the current thread?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6311) cs_FailedStreamInsertCharBufferBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby2017LayerATest)java.sql.SQLException: Exception during restore of a s
[ https://issues.apache.org/jira/browse/DERBY-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777638#comment-13777638 ] Kathey Marsden commented on DERBY-6311: --- Saw this September 23, IBM 1.5 on 10.8 http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm15/1525188-suites.All_diff.txt cs_FailedStreamInsertCharBufferBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby2017LayerATest)java.sql.SQLException: Exception during restore of a serializable or SQLData object of class --- Key: DERBY-6311 URL: https://issues.apache.org/jira/browse/DERBY-6311 Project: Derby Issue Type: Bug Components: Network Client Affects Versions: 10.11.0.0 Environment: Windows IBM JDK 1.7 Reporter: Kathey Marsden Saw this failure in the nightlies http://cloudsoft.svl.ibm.com/intranet/nightlies/derbywinvm/JarResults.2013-08-13/ibm17_suites.All/suites.All.out 1) cs_FailedStreamInsertCharBufferBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby2017LayerATest)java.sql.SQLException: Exception during restore of a serializable or SQLData object of class at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.ClientStatement.executeQuery(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby2017LayerATest.doInsertTest(Derby2017LayerATest.java:559) at org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby2017LayerATest.cs_FailedStreamInsertCharBufferBoundaries(Derby2017LayerATest.java:166) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:76) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:439) at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:456) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: org.apache.derby.client.am.SqlException: Exception during restore of a serializable or SQLData object of class at org.apache.derby.client.am.ClientStatement.completeSqlca(Unknown Source) at org.apache.derby.client.am.ClientStatement.completeOpenQuery(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseOpenQueryFailure(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(Unknown Source) at org.apache.derby.client.net.NetStatementReply.readOpenQuery(Unknown Source) at org.apache.derby.client.net.StatementReply.readOpenQuery(Unknown Source) at org.apache.derby.client.net.NetStatement.readOpenQuery_(Unknown Source) at org.apache.derby.client.am.ClientStatement.readOpenQuery(Unknown Source) at org.apache.derby.client.am.ClientStatement.flowExecute(Unknown Source) at org.apache.derby.client.am.ClientStatement.executeQueryX(Unknown Source) ... 38 more Caused by: org.apache.derby.client.am.SqlException: Java exception: ': java.io.UTFDataFormatException'. at org.apache.derby.client.am.SqlException.init(Unknown Source) at org.apache.derby.client.am.SqlException.init(Unknown Source) ... 48 more FAILURES!!! Tests run: 17765, Failures: 0, Errors: 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6146) nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFai
[ https://issues.apache.org/jira/browse/DERBY-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777699#comment-13777699 ] Kathey Marsden commented on DERBY-6146: --- So looking at the test we have // Give the other thread a little while to start and obtain the // lock on the last record. Thread.sleep(1000); // The last record should be locked now, so this call will have to // wait initially. This statement used to cause an assert failure in // debug builds before DERBY-4193. JDBC.assertSingleValueResultSet( s.executeQuery(select max(x) from max_scan + --DERBY-PROPERTIES index=IDX), 4); Where the thread that we are waiting for inserts the 4 that we expect to see. So maybe the Thread.sleep(1000) is just not long enough sometimes. Perhaps the test should synchronize the two threads in a different way. I will try first eliminating the sleep to see if it makes the failure more likely to happen. nightly regression test failure: testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', - Key: DERBY-6146 URL: https://issues.apache.org/jira/browse/DERBY-6146 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.3.1, 10.9.2.2 Environment: windows, ibm16 Reporter: Mike Matrigali http://people.apache.org/~myrnavl/derby_test_results/v10_8/windows/testlog/ibm16/1461387-suites.All_diff.txt 1) testMultipleLastKeyWaitsInMaxScan(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: Column value mismatch @ column '1', row 1: Expected: 4 Found:3 at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1213) at org.apache.derbyTesting.junit.JDBC.assertRowInResultSet(JDBC.java:1125) at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.java:1012) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.junit.JDBC.assertSingleValueResultSet(JDBC.java:835) at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testMultipleLastKeyWaitsInMaxScan(IndexSplitDeadlockTest.java:657) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:110) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 15197, Failures: 1, Errors: 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6350) Provide a rolling file implementation of derby.log
[ https://issues.apache.org/jira/browse/DERBY-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777934#comment-13777934 ] Kathey Marsden commented on DERBY-6350: --- I think it is ok for it to work in soft upgrade format. I think in general we limit the soft upgrade restriction to features that change on-disk format. Provide a rolling file implementation of derby.log -- Key: DERBY-6350 URL: https://issues.apache.org/jira/browse/DERBY-6350 Project: Derby Issue Type: Improvement Components: Miscellaneous Reporter: Brett Bergquist Priority: Minor Labels: features Attachments: rollingfilelog.patch.txt, rollingfilelog.patch.txt By default, derby.log grows without bounds if the derby.infolog.append property is set to true. Setting this to true helps in a hands off production environment to ensure that if Derby restarts, the derby.log which might contain important information is not lost. On the other hand, when set the true the derby.log grows without bounds. This is problematic in a long running system. What is really needed is the ability to have a rolling derby.log file support where the maximum file size and maximum number of files can be specified. Derby has the ability to configure the location of the log file (ie. derby.stream.error.file) and also two methods of redirecting the error stream (.ie derby.stream.error.method and derby.stream.error.field). There is no standard implementation that supports a rolling derby.log however. This facility should be part of the core Derby system so that it works in both embedded and network server models. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[ https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden updated DERBY-5610: -- Attachment: derby-5610_2_diff.txt Attaching a patch that puts the e.printStackTrace() in a if (debugOutput) block. I am hesitant to remove it completely. ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes -- Key: DERBY-5610 URL: https://issues.apache.org/jira/browse/DERBY-5610 Project: Derby Issue Type: Bug Components: Network Server Affects Versions: 10.8.3.0 Reporter: Kathey Marsden Assignee: Kathey Marsden Priority: Minor Labels: derby_triage10_9 Fix For: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0 Attachments: derby-5610_2_diff.txt, derby-5610_diff.txt, derby-5610_trunkdiff.txt ServerPropertiesTest showed the below output when running. The ping retries and the test passes. I am not sure if in fact a Connection reset is a valid response if the server is not fully up and the test is just being too verbose or if it is real problem that we get this Error. .java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.net.SocketInputStream.read(SocketInputStream.java:90) at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source) at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source) at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309) at org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) java.net.SocketException: Connection reset at
[jira] [Resolved] (DERBY-6349) DaylightSavingTest - java.security.AccessControlException
[ https://issues.apache.org/jira/browse/DERBY-6349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kathey Marsden resolved DERBY-6349. --- Resolution: Fixed Fix Version/s: 10.11.0.0 10.10.1.3 DaylightSavingTest - java.security.AccessControlException - Key: DERBY-6349 URL: https://issues.apache.org/jira/browse/DERBY-6349 Project: Derby Issue Type: Bug Environment: IBM internal prerelease JVM Reporter: Kathey Marsden Assignee: Kathey Marsden Fix For: 10.10.1.3, 10.11.0.0 Attachments: TimeZoneSecurity_diff.txt Seeing this test failure because of an intentional security change in TimeZone.setDefault(). Therefore need to wrap Timezone.setDefault in a priv block in the test. 1) DaylightSavingTestjava.security.AccessControlException: Access denied (java.util.PropertyPermission user.timezone write) at java.security.AccessController.throwACE(AccessController.java:10 0) at unknown class.unknown method(Unknown Source) at java.lang.SecurityManager.checkPermission(SecurityManager.java:5 49) at java.util.TimeZone.hasPermission(TimeZone.java:756) at java.util.TimeZone.setDefault(TimeZone.java:778) at org.apache.derbyTesting.junit.TimeZoneTestSetup.setUp(TimeZoneTe stSetup.java:59) at junit.extensions.TestSetup$1.protect(TestSetup.java:22) at junit.extensions.TestSetup.run(TestSetup.java:27) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.ja va:57) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5610) ServerPropertiesTest prints .java.net.SocketException: Connection reset to console but test passes
[
https://issues.apache.org/jira/browse/DERBY-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13775668#comment-13775668
]
Kathey Marsden commented on DERBY-5610:
---
So I think the problem comes down to consoleExceptionPrintTrace which has
public void consoleExceptionPrintTrace(Throwable e)
{
consoleMessage(e.getMessage(), true);
PrintWriter lw = logWriter;
if (lw != null)
{
synchronized (lw) {
e.printStackTrace(lw);
}
}
else
{
e.printStackTrace(); == Problem with API ping printing stack trace
}
For the API calls no logwriter is set so it goes to the e.printStackTrace(). I
am wondering what is the case where this would be necessary or desirable.
ServerPropertiesTest prints .java.net.SocketException: Connection reset to
console but test passes
--
Key: DERBY-5610
URL: https://issues.apache.org/jira/browse/DERBY-5610
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.8.3.0
Reporter: Kathey Marsden
Assignee: Kathey Marsden
Priority: Minor
Labels: derby_triage10_9
Fix For: 10.8.3.1, 10.9.2.2, 10.10.1.3, 10.11.0.0
Attachments: derby-5610_diff.txt, derby-5610_trunkdiff.txt
ServerPropertiesTest showed the below output when running. The ping retries
and the test passes.
I am not sure if in fact a Connection reset is a valid response if the server
is not fully up and the test is just being too verbose or if it is real
problem that we get this Error.
.java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.net.SocketInputStream.read(SocketInputStream.java:90)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown
Source)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown Source)
at
org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown
Source)
at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown
Source)
at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source)
at
org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567)
at
org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.canPingServer(ServerPropertiesTest.java:280)
at
org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.shutdownServer(ServerPropertiesTest.java:309)
at
org.apache.derbyTesting.functionTests.tests.derbynet.ServerPropertiesTest.ttestSetPortPriority(ServerPropertiesTest.java:484)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.extensions.TestSetup.run(TestSetup.java:23)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at
[jira] [Commented] (DERBY-6350) Provide a rolling file implementation of derby.log
[ https://issues.apache.org/jira/browse/DERBY-6350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13773807#comment-13773807 ] Kathey Marsden commented on DERBY-6350: --- Thank you Brett for adding this useful functionality. I think it will be a great relief to many users and support people. I wonder if we could avoid the reference to org.apache.derby.impl.services.stream.RollingFileStreamProvider.getOutputStream by just making it so that implicit in setting any of the derby.stream.error.rollingfile properties. Provide a rolling file implementation of derby.log -- Key: DERBY-6350 URL: https://issues.apache.org/jira/browse/DERBY-6350 Project: Derby Issue Type: Improvement Components: Miscellaneous Reporter: Brett Bergquist Priority: Minor Labels: features Attachments: rollingfilelog.patch.txt By default, derby.log grows without bounds if the derby.infolog.append property is set to true. Setting this to true helps in a hands off production environment to ensure that if Derby restarts, the derby.log which might contain important information is not lost. On the other hand, when set the true the derby.log grows without bounds. This is problematic in a long running system. What is really needed is the ability to have a rolling derby.log file support where the maximum file size and maximum number of files can be specified. Derby has the ability to configure the location of the log file (ie. derby.stream.error.file) and also two methods of redirecting the error stream (.ie derby.stream.error.method and derby.stream.error.field). There is no standard implementation that supports a rolling derby.log however. This facility should be part of the core Derby system so that it works in both embedded and network server models. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-6341) LOB streaming not working with ClientDriver - IOException: object already closed
[
https://issues.apache.org/jira/browse/DERBY-6341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13772071#comment-13772071
]
Kathey Marsden commented on DERBY-6341:
---
I guess the question from a Derby perspective is whether the stream should be
accessible after the result set is closed. I tend to think that the close of
the result set by JPA means that the stream should also be closed, but I could
be wrong and welcome feedback. Perhaps there is a JPA bug that the result set
is getting closed at the wrong time?
LOB streaming not working with ClientDriver - IOException: object already
closed
Key: DERBY-6341
URL: https://issues.apache.org/jira/browse/DERBY-6341
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.10.1.1
Reporter: Gary Shank
I have a small test program using OpenJPA v2.2.2 with Derby database
10.10.1.1 and the Derby org.apache.derby.jdbc.ClientDriver. I also tried
ClientDriver40.
My entity is defined like this:
@Entity(name = BLOB_TEST)
public class BlobTest implements java.io.Serializable {
public BlobTest() {}
@Id @Column(name = PRIM_KEY, columnDefinition=VARCHAR(10))
private String primKey = null;
public void setKey(String key) { primKey = key; }
public String getKey() { return primKey; }
@Persistent @Column(name = DATA)
private InputStream data = null;
public void setData(InputStream data) { this.data = data; }
public InputStream getData() { return data; }
}
Putting data into the database works fine:
EntityManager em = open(); // performs configuration and
emf.createEntityManager();
em.getTransaction().begin();
FileInputStream fis = new FileInputStream(someInputFile);
BlobTest bt = new BlobTest();
bt.setKey(1);
bt.setData(fis);
em.persist(bt);
em.getTransaction().commit();
em.close();
Getting the data fails with IOException: The object is already closed. when
any InputStream.read method is called:
EntityManager em = open(); // performs configuration and
emf.createEntityManager();
BlobTest bt = em.find(BlobTest.class, 1); // the record is found
InputStream is = bt.getData();
while ( (bytesRead = is.read(buffer, 0, len)) != -1 )
java.io.IOException: The object is already closed.
at org.apache.derby.client.am.CloseFilterInputStream.read(Unknown Source)
Getting the data works if I use JDBC directly like this:
EntityManager em = open(); // performs configuration and
emf.createEntityManager();
Connection conx =
(Connection)org.apache.openjpa.persistence.OpenJPAPersistence.cast(em).getConnection();
PreparedStatement pstmt = conx.prepareStatement(select DATA from BLOB_TEST
where PRIM_KEY='1');
ResultSet rs = pstmt.executeQuery();
InputStream is = rs.getBinaryStream(1);
while ( (bytesRead = is.read(buffer, 0, len)) != -1 )
Is this a bug or am I just doing something wrong? My code has to work with
multiple databases so I can't really use JDBC directly - which is I opted for
using OpenJPA. I'm not sure if this is an OpenJPA issue or Derby issue but,
at the moment, I'm assuming is a problem with the client driver. By the way,
I did not test with the embedded driver since we need it to work with the
client driver. I've looked at the following other issues:
DERBY-3646 mentions object already close and the CloseFilterInputStream
OPENJPA-1248 - LOB streaming does not work as expected
OPENJPA-130 - use of InputStream for LOB streaming
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
