[
https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850812#action_12850812
]
Knut Anders Hatlen commented on DERBY-4584:
-------------------------------------------
Hi Tiago,
Thanks for the patch. I think there are some problems with this approach:
1) The javadoc for java.lang.String#getBytes(java.lang.String) says that the
behaviour is unspecified if the string cannot be encoded in the given charset.
So we cannot rely on that method to replace non-ascii characters with question
marks.
2) The String constructor should also take the charset name as an argument so
that the code works regardless of what the system default encoding is.
3) We should avoid printing exceptions on the console. I think it would be
better instead to do a "throw SqlException.javaException(agent_.logWriter, e)".
4) EBCDIC supports more characters than US-ASCII does, so this approach will
also replace some valid EBCDIC characters with question marks.
I noticed that EbcdicCcsidManager.convertFromUCS2() has commented out code to
generate a question mark instead of raising an exception for multi-byte
characters. Would it be possible to add a flag to re-enable that code and call
the method with that flag when converting extnam_ to EBCDIC in
NetConnection.constructPrddta()?
> Unable to connect to network server if client thread name has Japanese
> characters
> ---------------------------------------------------------------------------------
>
> Key: DERBY-4584
> URL: https://issues.apache.org/jira/browse/DERBY-4584
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0,
> 10.5.1.1, 10.5.2.0, 10.5.3.0
> Reporter: Brett Wooldridge
> Assignee: Tiago R. Espinha
> Attachments: DERBY-4584.diff
>
>
> I am opening this bug, which is probably a duplicate of bug#728 so that
> other's may find it and save the hours I spent chasing it down. Feel free to
> mark this as a duplicate. 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
> ストリングに変換することはできません。
> at
> org.apache.derby.client.net.EbcdicCcsidManager.convertFromUCS2(Unknown 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
> org.apache.derby.client.net.NetConnectionRequest.writeExchangeServerAttributes(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown 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
> org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown
> Source)
> at
> org.apache.derby.client.net.NetXAConnection.createNetConnection(Unknown
> Source)
> at org.apache.derby.client.net.NetXAConnection.<init>(Unknown Source)
> at
> org.apache.derby.client.ClientPooledConnection.getNetXAConnection(Unknown
> Source)
> ... 45 more
> However, the difference is that the database name (and connection URL) does
> NOT contain unicode characters. In this case, the *thread name* 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 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 10.0.0...@default)"
> If the Japanese is removed from the thread names, there is no problem.
> The workaround in our case was to change the thread names in our code to not
> contain Japanese characters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
