db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Wooldridge <brett.wooldri...@gmail.com>
Subject Connection failure when client thread name contains Japanese characters
Date Tue, 16 Mar 2010 06:48:04 GMT
Just a note to the list so that user's searching for this issue via google
might find this post. I have opened a bug (#4584), which is probably a
duplicate of bug#728 so that other's may find it and save the hours I spent
chasing it down. However, while related, it may not be a true duplicate of
728. The exception is similar to 728: Exception in thread "main"
org.apache.derby.client.am.SqlException: Unicode string can't convert to
Ebcdic string (Here is the version of the exception I received -- excuse the
Japanese characters): Caused by: org.apache.derby.client.am.SqlException:
Unicode ストリングを EBCDIC ストリングに変換することはできません。
Source) at org.apache.derby.client.net.Request.writeScalarString(Unknown
Source) at org.apache.derby.client.net.Request.writeScalarString(Unknown
Source) at
org.apache.derby.client.net.NetConnectionRequest.buildEXTNAM(Unknown Source)
at org.apache.derby.client.net.NetConnectionRequest.buildEXCSAT(Unknown
Source) at
Source) at
Source) at
Source) at
Source) at org.apache.derby.client.net.NetConnection.flowConnect(Unknown
Source) at org.apache.derby.client.net.NetConnection.initialize(Unknown
Source) at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
at org.apache.derby.client.net.NetConnection40.<init>(Unknown Source) at
Source) at
Source) at org.apache.derby.client.net.NetXAConnection.<init>(Unknown
Source) at
Source) ... 45 more However, the difference between #728 and this issue is
that the database name (and connection URL) does NOT contain unicode
characters. In this case, the *thread name* of a client thread requesting a
connection contains Japanese characters. If the thread performing
java.sql.DriverManager.getConnection() has characters that cannot be
translated into EBCDIC the above exception is the result.

If the thread name is changed to contain only standard ASCII characters, the
connection to the DB is successful. Note again, in my case, the connection
URL is a standard connection URL with no i18n characters, something similar
to: jdbc:derby://localhost/database It is only the client thread-name that
contains i18n characters. I don't know why the client feels it necessary to
marshall the client-thread name, but that seems to be the problem. The fix
for this issue is likely easier than 728 if the requirement that the client
marshall the thread name can be removed (it seems senseless). Finally, just
for the record, a typical thread name that tickles this bug is: "Running-2
(MOTDバナーの設定 for" If the Japanese is removed from the
thread names, there is no problem. No reproduction is attached; just change
the name of a client thread to contain invalid EBCDIC characters and attempt
to call getConnection().

View raw message