Only send RDBNAM on ACCSEC if EBCDIC conversion is possible

• Key: DERBY-4008
• Type: Sub-task
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Kathey Marsden
• Reporter: Kathey Marsden
• Component/s: Network Client
• Affects Version/s: 10.5.1.1
• Fix Version/s: 10.5.1.1

Description

As part of the change for DERBY-728 we will implement UNICODEMGR which will require ACCSEC be sent in EBCDIC. After DERBY-4004 is fixed the client should send the RDBNAM on ACCSEC only if EBCDIC conversion is possible. This will maintain compatibility with old servers for database names that can be converted but will allow us to defer sending the database name to SECCHK so that we can send the RDBNAM in UTF-8 with new servers when UNICODEMGR is active.

Comments

[Kathey Marsden]

As discussed in DERBY-728, this change while necessary to move forward on DERBY-728 will cause a regression when a new client tries to connect to an old server with a database name that can't be converted. If connecting with a Chinese database name with a new client and an old server, the server console will show an exception:
Execution failed because of a Distributed Protocol Error: DRDA_Proto_SYNTAXRM; CODPNT arg = 2110; Error Code Value = e
. Plaintext connection attempt from an SSL enabled client?


At the client we can save off the conversion exception that prevented us from sending the RDBNAM on ACCSEC and do one of two things.
  1) Report the SYNTAXRM on the client but chain the conversion exception, so it is clear the root cause of the problem.
  2) Gobble up the SYNTAXRM and just throw the conversion exception, so it looks like there was no SYNTXRM on the client and the client behavior matches the current behavior.

I am a bit wary of throwing away the exception so I am planning to go with option 1 which would be less compatible but have a cleaner implementation and wouldn't cause the SYNTAXRM to mysteriously disappear between server and client. I will backport DERBY-4004 so that folks using newer 10.3 and 10.4 servers won't be affected. I'll post a patch soon with my proposal. Please post if you have any concerns or other ideas.

[Kathey Marsden]

Attached is a patch for this issue. It changes the client to not send the RDBNAM on ACCSEC if EBCDIC conversion is not possible. For a 10.5 client to 10.5 server there is no behavior change except that the exception for conversion exception comes a bit later (on SECCHK) instead of ACCSEC.

As discussed, for 10.5 client talking to older servers, this will cause a change in the exception when trying to connect with a non-convertible database name. Users will instead get a SYTAXRM with a chained conversion exception. I will backport DERBY-4004 to mitigate this and also make a release note for this issue.

Also added tests for connection attempts with Chinse database name, user and password with DriverManager, Simple DataSource, XADataSource, and ConnectionPoolDataSource.

Running tests now.

[Kathey Marsden]

Regression tests passed. Please review

[Kathey Marsden]

I'll commit this patch Monday if there are no comments.

[Kathey Marsden]

The database directories created in the tests were not getting removed properly. This patch corrects that.

[Kathey Marsden]

Ataching a release note for this issue, which won't be entirely true until I backport derby-4004 to 10.4 and 10.3

[Myrna van Lunteren]

10.5 rel mgr work - replacing <br> with <br/> so the releaseNotesGenerator can chew it.