[
https://issues.apache.org/jira/browse/DERBY-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5096:
----------------------------------
Attachment: TestLowerCaseTraversal.java
Hi Steven,
On iseries I believe there is a java bug with getCanonicalPath() that can cause
this problem. If you run the attached program TestLowerCaseTraversal.java on
iseries, I think you will see that getCanonical path is not properly resolving
the case in the parent directories
$ java TestLowerCaseTraversal
mkdirs to create dir with mixedcase string: test/NDee = true
Original string: test/ndee/subdir
cannonical path before mkdirs(), should be mixed case as that's what's on the
machine: /home/MYRNA/tst/test/b11740/try4/test/ndee/subdir <<== Should be NDee!
created the subdir? true
cannonical path after mkdirs():
/home/MYRNA/tst/test/b11740/try4/test/NDee/subdir
On Windows XP, I see the case properly resolved:
mkdirs to create dir with mixedcase string: test/NDee = true
Original string: test/ndee/subdir
cannonical path before mkdirs(), should be mixed case as that's what's on the ma
chine: C:\cygwin\home\kmarsden\repro\11740\test\NDee\subdir
created the subdir? true
cannonical path after mkdirs(): C:\cygwin\home\kmarsden\repro\11740\test\NDee\s
ubdir
The workaround on iseries is to use the matching case for the path of the
database.
Another situation where there is a problem with getCanonicalPath() on iseries
that can cause this symptom is if there are multi-byte characters in the
database name. (See DERBY-4149). I don't know a good work around for that one.
I cannot speak to the vmware issues, but wonder if there is a casing or
getCanonicalPath issue there too.
> DisconnectException: "Connection was refused because the database DB was not
> found" when creating db for first time
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5096
> URL: https://issues.apache.org/jira/browse/DERBY-5096
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.7.1.1
> Environment: System: OS/400 V7R1M0 on PowerPC; JVM: IBM J9 VM 2.4
> (consistently reproducible).
> But also: Windows 2008 R2 on VMWare and Windows 7 64 bit with Sun VM (1.6)
> too (but not as consistently reproducible)
> Reporter: Steven Hendrickx
> Attachments: TestLowerCaseTraversal.java, getconnection_reproduce.zip
>
>
> A process starts derby as network server (new NetworkServerControl, start)
> and waits for derby to respond (retry ping until success). After the server
> has started, the same process makes a connection with
> DriverManager.getConnection().
> The first time this process runs, this will always fail with
> "SQLNonTransientConnectionException: The connection was refused because the
> database Flows;create=true was not found." However, at the same time,
> "derby.log" and "Flows" directory are created in the derby home. The "Flows"
> directory contains "log", "seg0", "tmp", "db.lck", "service.properties", etc
> ...
> The second time the process is started, the connection will succeed and the
> "Flows" database can be used successfully. From now on, every start will be
> successful. After cleaning the derby home directory, you get the exception
> again after the first start.
> The attachment contains a Java program (DerbyGetConnection.java) that
> reproduces this problem consistently on our OS/400 V7R1M0 with IBM J9 VM.
> Probably this may happen on other systems too (Win7), but we were unable to
> reproduce it there (on my machine with Win7, this same program ran successful
> every run; might be a threading or I/O issue that occurs easily on slower
> hardware?).
> The attachment contains also derby tracing ("derby.drda.traceAll") and
> logging/tracing of the DriverManager.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
