db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6888) Large User-Defined Types break Network Client
Date Wed, 04 May 2016 02:02:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270009#comment-15270009
] 

Rick Hillegas commented on DERBY-6888:
--------------------------------------

A workaround would be to write a server-side function which serializes he UDT into a long
VARBINARY and then deserialize it in the client-side application after calling PreparedStatement.getBytes().
So your query would look something like this:

select toVarbinary(myUDT) from ...


> Large User-Defined Types break Network Client
> ---------------------------------------------
>
>                 Key: DERBY-6888
>                 URL: https://issues.apache.org/jira/browse/DERBY-6888
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.11.1.1, 10.12.1.1
>            Reporter: Steven Schaefer
>         Attachments: udt_network_repro.zip
>
>
> In the project I work on at Nexidia we have been working with a derby in probably an
unusual way where we make use of both the embedded and network clients.
> We also make some use of user-defined types and have run into some inconsistencies between
those clients.
> Occasionally some of our user-defined types are above 32k. This is ok for the embedded
client; it seems to read and write those without issue. However, the network client has some
serious trouble.
> 1) Writes: The network client doesn't allow writing UDTs above 32k. I get this helpful
error message (more on this at the end...) "java.sql.SQLDataException: The resulting value
is outside the range for the data type 32767." Stack trace ends up pointing to org.apache.derby.client.net.Request.writeUDT,
and its code shows a hardcoded check.
> 2) Reads: Since our (multi-server) system runs with both clients for different needs,
our embedded client helpfully inserts UDTs greater than 32k. The network client doesn't appreciate
this much. Reading one of these large UDTs results in the following: "java.sql.SQLNonTransientConnectionException:
Insufficient data while reading from the network - expected a minimum of 6 bytes and received
only 0 bytes.  The connection has been terminated".
> Even better, the next time we try to create a new connection, it fails with "java.sql.SQLNonTransientConnectionException:
A network protocol error was encountered and the connection has been terminated: A protocol
error (Data Stream Syntax Error) was detected.  Reason: 0x19. Perhaps this is an attempt to
open a plaintext connection to an SSL enabled server."
> 3) With debug jars, #1's error message format fails an assertion check: {quote}
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Number of parameters
expected for message id 22003 (1) does not match number of arguments received (2)
> 	at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> 	at org.apache.derby.shared.common.i18n.MessageUtil.formatMessage(MessageUtil.java:209)
> 	at org.apache.derby.shared.common.i18n.MessageUtil.getCompleteMessage(MessageUtil.java:118)
> 	at org.apache.derby.shared.common.i18n.MessageUtil.getCompleteMessage(MessageUtil.java:158)
> 	at org.apache.derby.shared.common.i18n.MessageUtil.getCompleteMessage(MessageUtil.java:74)
> 	at org.apache.derby.client.am.SqlException.<init>(SqlException.java:169)
> 	at org.apache.derby.client.am.SqlException.<init>(SqlException.java:203)
> 	at org.apache.derby.client.net.Request.writeUDT(Request.java:1418)
> {quote}    
>     
> h5. Expected
> I expect some consistency here between the two clients. Either both accept UDTs greater
than 32k, or both reject them. Further, if a limit of 32k is still intended, it'd be great
of documentation was a bit loud about that limitation. DERBY-4491 comments indicate some sort
of "large UDT" may be appropriate, but it's not immediately clear to me if that's still needed.
And of course I expect subsequent connections to succeed! I'm also a little surprised large
blobs seem to work ok in this scenario, but I'm hoping that's an indication UDTs shouldn't
be limited to 32k too.
> We've been able to refactor out the network client to workaround the issue, but it's
not yet clear if this is an ideal long-term solution for us.
> h5. Reproducing:
> I have attached several sample programs:
> * *EmbeddedTest*: Inserts & Selects a blob and UDT that's 50k. I expect this program
to run without issue.
> * *NetworkWriteTest*: Attempts to insert a blob and UDT that's 50k. This will demonstrate
blobs are ok here, but #1 for UDTs (or #3 with debug jars).
> * *NetworkLargeUDTReadTest*: This demonstrates #2. It will attempt to read the large
UDT written by EmbeddedTest. Finally, it will then try to create a new connection demonstrating
the 0x19 error.
> h5. To run:
> * unzip, then cd udt_network_repo
> * gradlew build
> * java -cp "build\libs\*" com.nexidia.udtrepro.EmbeddedTest \[preferred derby home\]
> * java -cp "build\libs\*" com.nexidia.udtrepro.NetworkWriteTest \[preferred derby home\]
> * java -cp "build\libs\*" com.nexidia.udtrepro.NetworkLargeUDTReadTest \[preferred derby
home\]
> Note: EmbeddedTest should be run before NetworkLargeUDTReadTest
> I have reproed all with 10.12 as well. All tests run in Windows 7 w/ Java 8 u77.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message