You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Brett Wooldridge (JIRA)" <ji...@apache.org> on 2010/03/16 07:42:27 UTC
[jira] Created: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
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.5.3.0, 10.5.2.0, 10.5.1.1, 10.4.2.0, 10.4.1.3, 10.3.3.0, 10.3.2.1, 10.3.1.4, 10.2.2.0, 10.2.1.6, 10.1.3.1, 10.1.2.1, 10.1.1.0, 10.0.2.1, 10.0.2.0
Reporter: Brett Wooldridge
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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849336#action_12849336 ]
Kathey Marsden commented on DERBY-4584:
---------------------------------------
As I recall EXTNAM is part of the EXTSAT command which will still be in EBCDIC, even with the new ACR https://issues.apache.org/jira/secure/attachment/12405588/ACR7007.pdf
So, I think maybe mapping multibyte characters to question marks or some such will be how we will need to handle this.
> 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
>
> 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852137#action_12852137 ]
Tiago R. Espinha commented on DERBY-4584:
-----------------------------------------
I was more concerned about this:
java.lang.Exception: DRDA_InvalidReplyHeader2.S:Invalid reply header from network server: Invalid string ?. Plaintext connection attempt to an SSL enabled server?
It's complaining about an invalid string composed of a question mark... but we'll wait to see tomorrow's regressions.
> 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
> Fix For: 10.6.0.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Assigned: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha reassigned DERBY-4584:
---------------------------------------
Assignee: Tiago R. Espinha
> 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
>
> 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.90@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.
[jira] Updated: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha updated DERBY-4584:
------------------------------------
Attachment: DERBY-4584-fix.diff
DERBY-4584-test.diff
That does the trick Knut.
I'm submitting two files now:
- DERBY-4584-test.diff
This adds a fixture to DRDAProtocolTest that makes the exception pop. For this test I'm using the Chinese character in DERBY-728 but it is equally good as a Japanese test for this purpose.
- DERBY-4584-fix.diff
This implements the fix as suggested and the fixture mentioned above no longer fails.
> 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-fix.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852123#action_12852123 ]
Knut Anders Hatlen commented on DERBY-4584:
-------------------------------------------
Looks like it only happened on one of the machines, so let's wait and see if it happens again or if it's just a glitch. It sounds unlikely that the changes made here should be preventing the network server from starting up.
> 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
> Fix For: 10.6.0.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852109#action_12852109 ]
Tiago R. Espinha commented on DERBY-4584:
-----------------------------------------
Knut,
I was looking at today's regression testing and this came up:
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/testlog/lin/929180-suitesAll_diff.txt
It only seems to happen in JVM 1.4 though... do you think this is related to my change?
> 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
> Fix For: 10.6.0.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Assigned: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali reassigned DERBY-4584:
-------------------------------------
Assignee: Mike Matrigali (was: Tiago R. Espinha)
> 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: Mike Matrigali
> Fix For: 10.6.1.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Closed: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha closed DERBY-4584.
-----------------------------------
Regressions look fine, so I'm closing the issue.
> 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
> Fix For: 10.6.0.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851341#action_12851341 ]
Tiago R. Espinha commented on DERBY-4584:
-----------------------------------------
suites.All ran without problems (just the "normal" replication test failure since I'm using a Windows box)
Next, I'll be running derbyall.
> 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-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Reopened: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden reopened DERBY-4584:
-----------------------------------
> 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
> Fix For: 10.6.1.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Updated: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha updated DERBY-4584:
------------------------------------
Attachment: DERBY-4584.diff
This patch uses Kathey's suggestion for the thread name.
The problem now remains as to how will we test this patch. Is there any way to get our thread names to show in Japanese?
> 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.90@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.
[jira] Closed: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha closed DERBY-4584.
-----------------------------------
Closing this issue. Since this issue is related to Japanese characters on the EXCSAT command (which must be negotiated in EBCDIC), there's nothing DERBY-728 can do here other than convert the characters into question marks like it has been done.
> 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
> Fix For: 10.5.3.1, 10.6.1.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ 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.90@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.
[jira] Resolved: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali resolved DERBY-4584.
-----------------------------------
Assignee: Tiago R. Espinha (was: Mike Matrigali)
Fix Version/s: 10.5.3.1
Resolution: Fixed
backported fix to 10.5, resolving as fixed and resetting original owner.
> 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
> Fix For: 10.5.3.1, 10.6.1.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851006#action_12851006 ]
Knut Anders Hatlen commented on DERBY-4584:
-------------------------------------------
Thanks, the fix looks fine to me, but I think we need to add comments to the code both in NetConnection and in the test, as the purpose of this code is not obvious just by looking at it. Also, I think the connection returned by BaseJDBCTestCase.openConnection(String) is not closed automatically by the test harness, so it needs to be closed manually in the test case. DRDAProtocolTest.tearDown() also needs to call super.tearDown().
> 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-fix.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850833#action_12850833 ]
Knut Anders Hatlen commented on DERBY-4584:
-------------------------------------------
As for testing, could we set the name of the JUnit execution thread with Thread.currentThread().setName("<string with Japanese characters>") in setUp() and reset it in tearDown()?
> 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.90@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.
[jira] Updated: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-4584:
----------------------------------
i am looking at backporting this issue to 10.5.
> 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: Mike Matrigali
> Fix For: 10.6.1.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Resolved: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-4584.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.6.0.0
Thanks, Tiago, for the new patch. It looks fine, and all the regression tests ran cleanly. Committed revision 929085.
> 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
> Fix For: 10.6.0.0
>
> Attachments: DERBY-4584-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Updated: (DERBY-4584) Unable to connect to network server if
client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha updated DERBY-4584:
------------------------------------
Attachment: DERBY-4584-test.diff
DERBY-4584-fix.diff
Thank you for your comments Knut. I'm uploading two new patches and I'll be running suites.All now.
> 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-fix.diff, DERBY-4584-fix.diff, DERBY-4584-test.diff, DERBY-4584-test.diff, 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850860#action_12850860 ]
Tiago R. Espinha commented on DERBY-4584:
-----------------------------------------
Hello Knut,
Thank you for your comments; I overlooked the fact that the behavior is unspecified but indeed, then we cannot use it. All things considered we might just use the method you suggested instead.
Maybe I can create an overload of convertFromUCS2() with an encodeExtraCharacters flag where I implement your suggestion, and then the existing method invokes that one with this flag set to false. This way we maintain the existing behavior for compatibility and we have a way to encode UCS2 strings in EBCDIC whenever the content of the extra characters isn't important.
You suggested though that we do this on the constructPrddta method, but is it wise to simply convert the EXTNAM on the fly rather than converting it in a definite manner when it is constructed? (constructExtnam())
If we simply convert it on the fly, then we must always be careful whenever we use the extnam_ as it will still contain UCS2 characters.
I'll also look into setting the name of threads like you mentioned; if this is possible, I'll also add a fixture to test this behavior.
> 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846740#action_12846740 ]
Dag H. Wanvik commented on DERBY-4584:
--------------------------------------
This code in org.apache.derby.client.net.NetConnection
is the source of this, presumably:
private void constructExtnam() throws SqlException {
extnam_ = "derbydnc" + java.lang.Thread.currentThread().getName();
}
This is a quantity of the DRDA protocol: (quote)
DRDA, Version 3, Volume 1, section 4.4.1 Accessing a Remote Relational Database Manager
"The extnam is the name of a job, task, or process that the application requester services.
It is used for diagnostic/logging purposes. In this example, it is the name of the job that
contains the execution of the application that is invoking application requester
functions on the OS/400 system.
Note: This parameter is required and must contain the name of the application requester's
execution thread in its operating environment. It must be a name that an observer of
the operating environment can easily associate with its execution."
I think there is a new version of DRDA coming that would allow Unicode in such strings; and if/when we move to that, it might solve this issue. A more immediate way to this is to algoritmically modify a non-EBCDIC thread name into something EBCDIC...
> 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
>
> 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.90@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.
[jira] Commented: (DERBY-4584) Unable to connect to network server
if client thread name has Japanese characters
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850882#action_12850882 ]
Knut Anders Hatlen commented on DERBY-4584:
-------------------------------------------
Looks like you're right, extnam_ is used and converted to EBCDIC more places than constructPrddta(), so it's probably best to do this in constructExtnam(). As far as I understand, we are able to convert all characters whose Unicode codepoint is less than 256 to EBCDIC, so perhaps something like this would do?
char[] chars = threadName.toCharArray();
for (int i = 0; i < chars.length; i++) {
if (chars[i] > 0xff) chars[i] = '?';
}
threadName = new String(chars);
> 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.90@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.