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 "A B (JIRA)" <de...@db.apache.org> on 2005/03/09 18:24:52 UTC
[jira] Created: (DERBY-170) Three Network Server problems related to large data transfer from server to client.
Three Network Server problems related to large data transfer from server to client.
-----------------------------------------------------------------------------------
Key: DERBY-170
URL: http://issues.apache.org/jira/browse/DERBY-170
Project: Derby
Type: Bug
Components: Network Server
Environment: Derby Network Server running with either JDBC or ODBC driver.
Reporter: A B
Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
The following three failures, all of which deal with large data in some form or another, can occur when an application is running against Derby Network Server. The failures are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client).
I'm filing all three failures as a single JIRA entry since they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure. A fix for this bug won't necessarily be a single patch--it's reasonable and acceptable that the different failures be addressed in different patches, and that the set of patches as a whole is considered the "fix" for this bug. Of course, if people prefer that I break this down into separate JIRA entries, feel free to say so.
Failure 1: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
Failure 2: When Derby Network Server tries to return ~32K or greater data as part of the result set for a stored procedure, a protocol exception occurs and causes deallocation of the connection. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "BIG_COL" declared in "storedProcs.java". Both files are attached to this bug.
Failure 3: Server hangs in communication with client when it (the server) tries to send a DSS continuation header to accommodate a high number (hundreds) of return columns from a Java procedure. Problem appears to be in the way the server creates the DSS continuation header. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "LOTS_O_COLS" declared in "storedProcs.java". Both files are attached to this bug.
NOTE: In order for the repros for #2 and #3 to work, you must compile "storedProcs.java" and include the storedProcs.class file in the _server_'s classpath.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.
Posted by Mamta Satoor <ms...@gmail.com>.
Bryan, it's very impressive the information you provide with your changes.
I am wondering if changes.html gets checked into the codeline somewhere or
does it stay in the JIRA entry for future reference?
Mamta
On 1/16/06, Kathey Marsden (JIRA) <de...@db.apache.org> wrote:
>
> [
> http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362883]
>
> Kathey Marsden commented on DERBY-170:
> --------------------------------------
>
> I checked in this change. Thanks Bryan for the patch.
>
> Date: Mon Jan 16 11:19:26 2006
> New Revision: 369549
>
> URL: http://svn.apache.org/viewcvs?rev=369549&view=rev
>
> One thing that would be good I think is to get more the great information
> in changes.html into the code comments.
> Of course the comments probably needn't contain as detailed an
> explanation as in the changes.html but a comment with the bug number
> pointing out the changes.html attached to the bug might be helpful to
> others looking at the code in the future.
>
>
> > Inserting large string value into non-existent table causes
> communication link failure over Network Server.
> >
> -----------------------------------------------------------------------------------------------------------
> >
> > Key: DERBY-170
> > URL: http://issues.apache.org/jira/browse/DERBY-170
> > Project: Derby
> > Type: Bug
> > Components: Network Server
> > Environment: Derby Network Server running with either JDBC or ODBC
> driver.
> > Reporter: A B
> > Assignee: Bryan Pendleton
> > Attachments: assert_repro.java, changes.html, storedProcs.java,
> stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
> >
> > The following failure, along with the 2 sub-tasks created under this
> issue, are reproducible both from a JDBC client (JCC) and from an ODBC
> client (in this case, DB2 Runtime Client). I've grouped them all together
> because they all share the characteristic of "large data transfer", though
> the context in which the transfer occurs is different for each failure.
> > Failure: When trying to insert a large string value (ex. 1 million
> chars) into a non-existent table using a prepared statement, an ASSERT
> failure occurs on the Derby side (because data size < 0), which leads to
> connection closure and communication link failure. Note that the problem
> does NOT happen if the target table actually exists. Repro can be found in
> the "assert_repro.java" file attached to this bug.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
[jira] Commented: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362883 ]
Kathey Marsden commented on DERBY-170:
--------------------------------------
I checked in this change. Thanks Bryan for the patch.
Date: Mon Jan 16 11:19:26 2006
New Revision: 369549
URL: http://svn.apache.org/viewcvs?rev=369549&view=rev
One thing that would be good I think is to get more the great information in changes.html into the code comments.
Of course the comments probably needn't contain as detailed an explanation as in the changes.html but a comment with the bug number pointing out the changes.html attached to the bug might be helpful to others looking at the code in the future.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362678 ]
Bryan Pendleton commented on DERBY-170:
---------------------------------------
I will investigate the client-side code, and I'll submit an updated patch against the latest trunk after doing so. If the client-side code appears to be the identical issue, I'll include it in the updated patch.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
A B updated DERBY-170:
----------------------
Summary: Inserting large string value into non-existent table causes communication link failure over Network Server. (was: Three Network Server problems related to large data transfer from server to client.)
Description:
The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
was:
The following three failures, all of which deal with large data in some form or another, can occur when an application is running against Derby Network Server. The failures are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client).
I'm filing all three failures as a single JIRA entry since they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure. A fix for this bug won't necessarily be a single patch--it's reasonable and acceptable that the different failures be addressed in different patches, and that the set of patches as a whole is considered the "fix" for this bug. Of course, if people prefer that I break this down into separate JIRA entries, feel free to say so.
Failure 1: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
Failure 2: When Derby Network Server tries to return ~32K or greater data as part of the result set for a stored procedure, a protocol exception occurs and causes deallocation of the connection. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "BIG_COL" declared in "storedProcs.java". Both files are attached to this bug.
Failure 3: Server hangs in communication with client when it (the server) tries to send a DSS continuation header to accommodate a high number (hundreds) of return columns from a Java procedure. Problem appears to be in the way the server creates the DSS continuation header. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "LOTS_O_COLS" declared in "storedProcs.java". Both files are attached to this bug.
NOTE: In order for the repros for #2 and #3 to work, you must compile "storedProcs.java" and include the storedProcs.class file in the _server_'s classpath.
I separated the three issues into different Jira tasks, per Kathy Marsden's suggestion. Thus this issue now only talks about one of the failures; the other two are subtasks.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton updated DERBY-170:
----------------------------------
Comment: was deleted
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362657 ]
Kathey Marsden commented on DERBY-170:
--------------------------------------
The change looks good. Thanks as always for the superb documentation.
A couple comments.
ensureBLayerDataInBuffer in client's Reply.java appears to have the same issue as ensureBLayerDataInBuffer in DDMReader.java. This could be a separate patch if you don't want to include client changes with this issue.
Knut's patch also changed DDMReader, so I applied to the older revision to review. Can you submit a new patch against the lastest trunk?
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
A B closed DERBY-170:
---------------------
Issue has been fixed, tested, and ported back to 10.1, so I'm now marking it as closed. Thanks Bryan!
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.4
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-170) Three Network Server problems related to large data transfer from server to client.
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=history ]
A B updated DERBY-170:
----------------------
Attachment: assert_repro.java
stored_proc_repro.java
storedProcs.java
Adding sample Java files to reproduce the three failures mentioned.
> Three Network Server problems related to large data transfer from server to client.
> -----------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following three failures, all of which deal with large data in some form or another, can occur when an application is running against Derby Network Server. The failures are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client).
> I'm filing all three failures as a single JIRA entry since they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure. A fix for this bug won't necessarily be a single patch--it's reasonable and acceptable that the different failures be addressed in different patches, and that the set of patches as a whole is considered the "fix" for this bug. Of course, if people prefer that I break this down into separate JIRA entries, feel free to say so.
> Failure 1: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
> Failure 2: When Derby Network Server tries to return ~32K or greater data as part of the result set for a stored procedure, a protocol exception occurs and causes deallocation of the connection. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "BIG_COL" declared in "storedProcs.java". Both files are attached to this bug.
> Failure 3: Server hangs in communication with client when it (the server) tries to send a DSS continuation header to accommodate a high number (hundreds) of return columns from a Java procedure. Problem appears to be in the way the server creates the DSS continuation header. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "LOTS_O_COLS" declared in "storedProcs.java". Both files are attached to this bug.
> NOTE: In order for the repros for #2 and #3 to work, you must compile "storedProcs.java" and include the storedProcs.class file in the _server_'s classpath.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton resolved DERBY-170:
-----------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
Fixed in the trunk by commit of revision 369549.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Fix For: 10.2.0.0
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton reopened DERBY-170:
-----------------------------------
Reopened to merge this fix to the 10.1 branch.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Fix For: 10.2.0.0
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton reassigned DERBY-170:
-------------------------------------
Assign To: Bryan Pendleton
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-170) Three Network Server problems related to large data transfer from server to client.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12317556 ]
Kathey Marsden commented on DERBY-170:
--------------------------------------
I tend to think three separate bugs subtasks for this bug would be good
> Three Network Server problems related to large data transfer from server to client.
> -----------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following three failures, all of which deal with large data in some form or another, can occur when an application is running against Derby Network Server. The failures are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client).
> I'm filing all three failures as a single JIRA entry since they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure. A fix for this bug won't necessarily be a single patch--it's reasonable and acceptable that the different failures be addressed in different patches, and that the set of patches as a whole is considered the "fix" for this bug. Of course, if people prefer that I break this down into separate JIRA entries, feel free to say so.
> Failure 1: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
> Failure 2: When Derby Network Server tries to return ~32K or greater data as part of the result set for a stored procedure, a protocol exception occurs and causes deallocation of the connection. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "BIG_COL" declared in "storedProcs.java". Both files are attached to this bug.
> Failure 3: Server hangs in communication with client when it (the server) tries to send a DSS continuation header to accommodate a high number (hundreds) of return columns from a Java procedure. Problem appears to be in the way the server creates the DSS continuation header. Repro can be found in the "stored_proc_repro.java" file, which uses the stored procedure "LOTS_O_COLS" declared in "storedProcs.java". Both files are attached to this bug.
> NOTE: In order for the repros for #2 and #3 to work, you must compile "storedProcs.java" and include the storedProcs.class file in the _server_'s classpath.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12360747 ]
Bryan Pendleton commented on DERBY-170:
---------------------------------------
Please see Derby-125 attachment "changes.html" for more information.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton updated DERBY-170:
----------------------------------
Attachment: changes.html
svn_jan12_2006.diff
svn_jan12_2006.status
Attached is a proposed patch for DERBY-170, which teaches the skipDSS method how to handle segmented DDM objects. There is also a small HTML file which provides a bit of background and discussion for the reviewer. I have successfully run derbyall with this patch. The patch includes a new test, and new master output files. Please review this patch at your convenience.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12360519 ]
Bryan Pendleton commented on DERBY-170:
---------------------------------------
(This comment refers *just* to DERBY-170. DERBY-491 and DERBY-492 are completely different problems and I'll have more to say about them later.)
The basis of the DERBY-170 problem is the method DDMReader.skipDss; this method does not properly handle large DDM Objects which are written using continued DSS data structures.
The way that the bug gets to this point is as follows:
1) The client sends a PRPSQLSTT to prepare the insert statement
2) The prepare fails because the table doesn't exist; the server correctly sends back an error message.
3) The client has already moved on to sending the DSCSQLSTT request. The server reads this, notices that the prepare failed, and skips through the request.
4) The client has already moved on to sending the EXCSQLSTT request. The server reads this, notices that the prepare failed, and calls skipRemainder to skip through the request.
This is where the problem occurs. The client has included the enormous character string as the parameter to the EXCSQLSTT; this parameter string is so long that it is continued through multiple 32K blocks. However, the skipRemainder method can't handle continued objects properly. What it does is to read the first block, note that it is a continued object, and then calls skipDSS to skip it. But skipDSS only skips the first 32K segment of the giant parameter; it doesn't skip the continued object segments. So the skipRemainder() method terminates without having digested the entire parameter object, and control pops out to the main processCommands loop, which then reads the next parameter object segment, tries to interpret it as a new DSS, and rejects it with an assert.
Here is the diff that I am currently experimenting with; so far, results have been promising. Please let me know your opinions on my analysis of the problem so far.
Index: DDMReader.java^M
===================================================================^M
--- DDMReader.java (revision 357039)^M
+++ DDMReader.java (working copy)^M
@@ -1348,6 +1348,11 @@^M
*/
protected void skipDss() throws DRDAProtocolException
{
+ while (dssIsContinued)
+ {
+ skipBytes((int)dssLength);
+ readDSSContinuationHeader();
+ }
skipBytes((int)dssLength);
topDdmCollectionStack = EMPTY_STACK;
ddmScalarLen = 0;
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, storedProcs.java, stored_proc_repro.java
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton resolved DERBY-170:
-----------------------------------
Fix Version: 10.1.3.0
10.1.2.4
Resolution: Fixed
Merged the fix from the trunk to 10.1 branch with subversion revision 397963. Updated Fix Version.
http://svn.apache.org/viewcvs?rev=397963&view=rev
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.4
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=comments#action_12362734 ]
Bryan Pendleton commented on DERBY-170:
---------------------------------------
Hi Kathey,
I looked at Reply.ensureBLayerDataInBuffer, and I believe that it does *not* have the same problem. The issue in DDMReader.java on the server side is that its implementation of ensureBLayerDataInBuffer, in the "is continued" case, was not calling ensureALayerDataInBuffer. The implementation on the client side is slightly different, and it always calls ensureALayerDataInBuffer, in both the "is continued" case and in the non-continued case. So I believe that the client code is correct with respect to this problem.
While stepping through the Reply.java code, I did see a few things that worried me:
- the comment which accompanies Reply.compressBLayerData seems almost totally wrong to me and I fear it could substantially mislead future readers of the code
- the implementation of Reply.compressBLayerData uses an inline for() loop to shift the bytes around, rather than calling System.arraycopy, which seems like it could be a performance problem.
However, neither of these seemed serious enough to warrant including into this particular patch.
Can you take another look at the client's Reply.java and let me know if you think I've misunderstood it?
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.diff, svn_jan12_2006.status
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton updated DERBY-170:
----------------------------------
Attachment: (was: svn_jan12_2006.diff)
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-170) Inserting large string value into
non-existent table causes communication link failure over Network Server.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-170?page=all ]
Bryan Pendleton updated DERBY-170:
----------------------------------
Attachment: svn_jan14_2006.diff
I updated my sandbox and attached a new diff against the latest trunk. Tests still run fine.
> Inserting large string value into non-existent table causes communication link failure over Network Server.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-170
> URL: http://issues.apache.org/jira/browse/DERBY-170
> Project: Derby
> Type: Bug
> Components: Network Server
> Environment: Derby Network Server running with either JDBC or ODBC driver.
> Reporter: A B
> Assignee: Bryan Pendleton
> Attachments: assert_repro.java, changes.html, storedProcs.java, stored_proc_repro.java, svn_jan12_2006.status, svn_jan14_2006.diff
>
> The following failure, along with the 2 sub-tasks created under this issue, are reproducible both from a JDBC client (JCC) and from an ODBC client (in this case, DB2 Runtime Client). I've grouped them all together because they all share the characteristic of "large data transfer", though the context in which the transfer occurs is different for each failure.
> Failure: When trying to insert a large string value (ex. 1 million chars) into a non-existent table using a prepared statement, an ASSERT failure occurs on the Derby side (because data size < 0), which leads to connection closure and communication link failure. Note that the problem does NOT happen if the target table actually exists. Repro can be found in the "assert_repro.java" file attached to this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira