db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tiago R. Espinha (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4584) Unable to connect to network server if client thread name has Japanese characters
Date Mon, 29 Mar 2010 09:44:27 GMT

    [ 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.


Mime
View raw message