[jira] Commented: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=comments#action_12360748 ] Bryan Pendleton commented on DERBY-491: --- Please see DERBY-125 for information on a proposed fix to this bug. > Protocol exception when Network Server tries to return ~32K

[jira] Commented: (DERBY-492) Server hangs when trying to return high number (hundreds) of columns from a Java procedure to the client.

[ http://issues.apache.org/jira/browse/DERBY-492?page=comments#action_12360749 ] Bryan Pendleton commented on DERBY-492: --- Please see DERBY-125 for information on a proposed fix to this bug. > Server hangs when trying to return high number (hundreds) o

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: (was: svn.diff) > Network Server can send DSS greater than 32K to client, which breaks DRDA > protocol. > --

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: svn_2.diff First diff included an accidental, unrelated change. Removed, and replaced with svn_2.diff. > Network Server can send DSS greater t

[jira] Commented: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement()

[ http://issues.apache.org/jira/browse/DERBY-333?page=comments#action_12360995 ] Bryan Pendleton commented on DERBY-333: --- I was interested in this bug, too, but I don't know the answer. The way that I read the code, the "if" statement is trying to be

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: (was: changes.html) > Network Server can send DSS greater than 32K to client, which breaks DRDA > protocol. > --

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: (was: svn_2.diff) > Network Server can send DSS greater than 32K to client, which breaks DRDA > protocol. >

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: changes2.html svn-dec_28_2005.diff Replaced "changes.html" with "changes2.html", which includes more details and two additional

[jira] Commented: (DERBY-326) Improve streaming of large objects for network server and client

[ http://issues.apache.org/jira/browse/DERBY-326?page=comments#action_12361391 ] Bryan Pendleton commented on DERBY-326: --- It seems as though there are a lot of modified lines in your patch, but many of them appear to be simply indentation/whitespace c

[jira] Commented: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=comments#action_12362549 ] Bryan Pendleton commented on DERBY-125: --- I am withdrawing this patch. It is unnecessarily large and complex, as it bundles multiple bug-fixes into one patch. I will submi

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: (was: changes2.html) > Network Server can send DSS greater than 32K to client, which breaks DRDA > protocol. > -

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: (was: svn-dec_28_2005.diff) > Network Server can send DSS greater than 32K to client, which breaks DRDA > protocol. > --

[jira] Updated: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

[ 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

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: changes.html svn_jan_12_2006.diff svn_jan_12_2006.status Attached is a focused patch which addresses *only* the p

[jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

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

[jira] Updated: (DERBY-492) Server hangs when trying to return high number (hundreds) of columns from a Java procedure to the client.

[ http://issues.apache.org/jira/browse/DERBY-492?page=all ] Bryan Pendleton updated DERBY-492: -- Comment: was deleted > Server hangs when trying to return high number (hundreds) of columns from a > Java procedure to the client. > ---

[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Attachment: changes.html svn_Jan_13_2006.status svn_Jan_13_3006.diff Attached is a patch proposal which addresses both this b

[jira] Commented: (DERBY-492) Server hangs when trying to return high number (hundreds) of columns from a Java procedure to the client.

[ http://issues.apache.org/jira/browse/DERBY-492?page=comments#action_12362694 ] Bryan Pendleton commented on DERBY-492: --- I believe that this bug, although it has dramatically different symptoms, is actually the same bug as DERBY-491. Please see DERBY

[jira] Updated: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

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

[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Comment: was deleted > Protocol exception when Network Server tries to return ~32K of data or > greater in a result set for a Java stored procedure. > -

[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12362711 ] Bryan Pendleton commented on DERBY-210: --- If I understand your comment correctly, you feel that you now have a correct fix, which avoids the memory leaks; however, you are

[jira] Commented: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

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

[jira] Updated: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

[ 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

[jira] Updated: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

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

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: (was: svn_jan_12_2006.diff) > Network Server can send DSS greater than 32K to client, which breaks DRDA > protocol. > --

[jira] Updated: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton updated DERBY-125: -- Attachment: svn_jan_22_2006.diff Attached is the latest patch proposal, updated to the latest trunk,with all conflicts resolved and derbyall passing. There

[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12363585 ] Bryan Pendleton commented on DERBY-210: --- Hi Deepa, thanks very much for posting your research, it was extremely interesting. I'm not sure I agree with Kathey, though. My

[jira] Commented: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server

[ http://issues.apache.org/jira/browse/DERBY-821?page=comments#action_12363717 ] Bryan Pendleton commented on DERBY-821: --- Maybe I'm not understanding your test program properly, but it seems that the result set should *not* be closed in this case, bec

[jira] Commented: (DERBY-816) In DDMWriter and DDMReader, use system routines in java.util.Arrays and System.arrayCopy

[ http://issues.apache.org/jira/browse/DERBY-816?page=comments#action_12363719 ] Bryan Pendleton commented on DERBY-816: --- I don't think there's much point in fiddling with padScalarStreamForError(), since Tomohito is working on removing that routine a

[jira] Created: (DERBY-863) Improve DDMWriter and DDMReader traces

Improve DDMWriter and DDMReader traces -- Key: DERBY-863 URL: http://issues.apache.org/jira/browse/DERBY-863 Project: Derby Type: Improvement Components: Network Server Versions: 10.1.1.0, 10.2.0.0 Reporter: Bryan P

[jira] Created: (DERBY-864) Network Client should not assume length of Layer B segment is 32K

Network Client should not assume length of Layer B segment is 32K - Key: DERBY-864 URL: http://issues.apache.org/jira/browse/DERBY-864 Project: Derby Type: Improvement Components: Network Client

[jira] Created: (DERBY-865) Under SanityManager/debug control, pre-fill DDMWriter buffers with garbage to expose memory corruption errors

Under SanityManager/debug control, pre-fill DDMWriter buffers with garbage to expose memory corruption errors - Key: DERBY-865 URL: http://issues.apache.org/jira/browse/DE

[jira] Created: (DERBY-867) Performance issues with large object handling in DDMWriter

Performance issues with large object handling in DDMWriter -- Key: DERBY-867 URL: http://issues.apache.org/jira/browse/DERBY-867 Project: Derby Type: Improvement Components: Network Server, Performance V

[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Attachment: svn_jan_24_2006.diff Updated patch, against latest trunk. I added a few additional comments to this patch to try to explain the changes more cle

[jira] Resolved: (DERBY-125) Network Server can send DSS greater than 32K to client, which breaks DRDA protocol.

[ http://issues.apache.org/jira/browse/DERBY-125?page=all ] Bryan Pendleton resolved DERBY-125: --- Fix Version: 10.2.0.0 Resolution: Fixed Fixed in the trunk with commit of revision 371603 > Network Server can send DSS greater than 32K to clie

[jira] Resolved: (DERBY-170) Inserting large string value into non-existent table causes communication link failure over Network Server.

[ 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

[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Attachment: (was: changes.html) > Protocol exception when Network Server tries to return ~32K of data or > greater in a result set for a Java stored pro

[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Attachment: changes.html > Protocol exception when Network Server tries to return ~32K of data or > greater in a result set for a Java stored procedure. > -

[jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

[ http://issues.apache.org/jira/browse/DERBY-491?page=all ] Bryan Pendleton updated DERBY-491: -- Attachment: svn_jan_26_2006.diff Updated the comments in the regression test to explain the test behavior more clearly and accurately, and to include a poin

[jira] Assigned: (DERBY-395) Server-side "trace on" and "trace off" commands do not appear to be working correctly.

[ http://issues.apache.org/jira/browse/DERBY-395?page=all ] Bryan Pendleton reassigned DERBY-395: - Assign To: Bryan Pendleton > Server-side "trace on" and "trace off" commands do not appear to be working > correctly. > --

[jira] Commented: (DERBY-395) Server-side "trace on" and "trace off" commands do not appear to be working correctly.

[ http://issues.apache.org/jira/browse/DERBY-395?page=comments#action_12364291 ] Bryan Pendleton commented on DERBY-395: --- I believe that the issue here is that ClientThread.java was mistakenly maintaining its own private cache of the values of the de

[jira] Updated: (DERBY-395) Server-side "trace on" and "trace off" commands do not appear to be working correctly.

[ http://issues.apache.org/jira/browse/DERBY-395?page=all ] Bryan Pendleton updated DERBY-395: -- Attachment: svn_jan_27_2006.diff svn.status Attached is a proposed fix. derbyall passed. I put a small comment in the code. I didn't add any

[jira] Resolved: (DERBY-395) Server-side "trace on" and "trace off" commands do not appear to be working correctly.

[ http://issues.apache.org/jira/browse/DERBY-395?page=all ] Bryan Pendleton resolved DERBY-395: --- Resolution: Fixed > Server-side "trace on" and "trace off" commands do not appear to be working > correctly. > --

[jira] Commented: (DERBY-877) zOS - with DerbyClient getDate(#) fails with IllegalArgumentException - unsupported date format - resultset.java

[ http://issues.apache.org/jira/browse/DERBY-877?page=comments#action_12364537 ] Bryan Pendleton commented on DERBY-877: --- Your change looks reasonable to me. I was able to reproduce the problem using your script, using Sun JDK 1.5 on Windows XP. I app

[jira] Updated: (DERBY-821) Client driver: Implicitly close exhausted result sets on the server

[ http://issues.apache.org/jira/browse/DERBY-821?page=all ] Bryan Pendleton updated DERBY-821: -- Attachment: changes-no-object-tags.html Hi Knut Anders, Your document is excellent. Thank you very much for writing it. The changes make much more sense to

[jira] Resolved: (DERBY-492) Server hangs when trying to return high number (hundreds) of columns from a Java procedure to the client.

[ http://issues.apache.org/jira/browse/DERBY-492?page=all ] Bryan Pendleton resolved DERBY-492: --- Resolution: Duplicate The symptoms are different, but the underlying bug is the same as DERBY-491. > Server hangs when trying to return high number (

[jira] Commented: (DERBY-745) DRDA Protocol Exception using DB2JCC driver and CLOBs from IJ

[ http://issues.apache.org/jira/browse/DERBY-745?page=comments#action_12365044 ] Bryan Pendleton commented on DERBY-745: --- I'm kind of at a dead-end with this problem. Here's what I know: - JCC sends an EXCSQLSTT for a statement without first sending a

[jira] Commented: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.

[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12365456 ] Bryan Pendleton commented on DERBY-928: --- I'd prefer the friendly string names (USER_ONLY_SECURITY, etc.). Actually, I'd prefer to use the friendly string names for *both*

[jira] Commented: (DERBY-100) Add support for insert functionality using JDBC 2.0 updatable resultset apis

[ http://issues.apache.org/jira/browse/DERBY-100?page=comments#action_12365687 ] Bryan Pendleton commented on DERBY-100: --- In java/client/org/apache/derby/client/am/ResultSet.java, I did not understand why you deleted the exit tracing at the end of the

[jira] Commented: (DERBY-668) SysInfo can give misleading information when JDBC jars are loaded from jre/lib/ext

[ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12365784 ] Bryan Pendleton commented on DERBY-668: --- Andrew McIntyre suggested that the getCodeSource() method included in the patch for DERBY-930 could be used to solve this issue,

[jira] Commented: (DERBY-557) Client driver gets OutOfMemoryError when re-executing statement without closing ResultSet

[ http://issues.apache.org/jira/browse/DERBY-557?page=comments#action_12366046 ] Bryan Pendleton commented on DERBY-557: --- This change looks good to me. The patch applies cleanly to the current trunk. I read through the test code and thought it was fin

[jira] Created: (DERBY-959) Allow use of DRDA QRYDTA block sizes greater than 32K

Allow use of DRDA QRYDTA block sizes greater than 32K - Key: DERBY-959 URL: http://issues.apache.org/jira/browse/DERBY-959 Project: Derby Type: Improvement Components: Network Client, Performance, Network Server

[jira] Updated: (DERBY-959) Allow use of DRDA QRYDTA block sizes greater than 32K

[ http://issues.apache.org/jira/browse/DERBY-959?page=all ] Bryan Pendleton updated DERBY-959: -- Description: Currently, the Network Server and Network Client use a 32K blocksize when returning database data in QRYDTA blocks. I came across the following

[jira] Commented: (DERBY-515) Network Server should log server start and shutdown time to derby.log

[ http://issues.apache.org/jira/browse/DERBY-515?page=comments#action_12366519 ] Bryan Pendleton commented on DERBY-515: --- I think this is quite nice -- thanks! I don't see any need to timestamp the trace or other messages at this time. I think we shou

[jira] Commented: (DERBY-962) Upgrade default security mechanism in client to use encrypted userid password if client can support it.

[ http://issues.apache.org/jira/browse/DERBY-962?page=comments#action_12366521 ] Bryan Pendleton commented on DERBY-962: --- I agree, Sunitha. If the user says something like: connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;u

[jira] Commented: (DERBY-960) Client xa prepare returns XA_OK instead of XA_RDONLY for a read only transaction

[ http://issues.apache.org/jira/browse/DERBY-960?page=comments#action_12366524 ] Bryan Pendleton commented on DERBY-960: --- > Should we bump the DRDA maintenance id and continue to return XA_OK with > older clients, > or just put this fix in place and

[jira] Updated: (DERBY-614) Execution failed because of a Distributed Protocol Error

[ http://issues.apache.org/jira/browse/DERBY-614?page=all ] Bryan Pendleton updated DERBY-614: -- Attachment: d614_a.diff Welcome back, JIRA! Attached is d614_a.diff, which contains the patch that Deepa found as well as a new regression test which demons

[jira] Assigned: (DERBY-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)

[ http://issues.apache.org/jira/browse/DERBY-428?page=all ] Bryan Pendleton reassigned DERBY-428: - Assign To: Bryan Pendleton > NetworkClient PreparedStatement.executeBatch() hangs if batch is too large > (ArrayIndexOutOfBoundsException in Network S

[jira] Updated: (DERBY-614) Execution failed because of a Distributed Protocol Error

[ http://issues.apache.org/jira/browse/DERBY-614?page=all ] Bryan Pendleton updated DERBY-614: -- Attachment: d614_a_with_close_stmts.diff Updated patch d614_a_with_close_stmts.diff addresses feedback from Dan and Deepa: the test should close the stateme

[jira] Commented: (DERBY-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)

[ http://issues.apache.org/jira/browse/DERBY-428?page=comments#action_12366806 ] Bryan Pendleton commented on DERBY-428: --- startDDM() is missing a call to ensureLength(). Many of the other problems that Bernt was seeing were due to DERBY-125 and DERBY-

[jira] Closed: (DERBY-614) Execution failed because of a Distributed Protocol Error

[ http://issues.apache.org/jira/browse/DERBY-614?page=all ] Bryan Pendleton closed DERBY-614: - Resolution: Fixed Thank you Kathey for submitting the second patch. > Execution failed because of a Distributed Protocol Error >

[jira] Commented: (DERBY-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)

[ http://issues.apache.org/jira/browse/DERBY-428?page=comments#action_12366874 ] Bryan Pendleton commented on DERBY-428: --- The crash on batch element 65535 seems pretty straightforward: correlation IDs in DSS blocks are 2-byte unsigned integers, so of

[jira] Commented: (DERBY-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)

[ http://issues.apache.org/jira/browse/DERBY-428?page=comments#action_12366899 ] Bryan Pendleton commented on DERBY-428: --- I believe that the 2-byte limit to the number of correlated commands in a single DRDA request is a hard limit. I've thought of t

[jira] Commented: (DERBY-515) Network Server should log server start and shutdown time to derby.log

[ http://issues.apache.org/jira/browse/DERBY-515?page=comments#action_12366971 ] Bryan Pendleton commented on DERBY-515: --- I checked derby-515-patch2-v1.diff. I thought it was a little odd that the diff contains changes to the two master files which a

[jira] Commented: (DERBY-515) Network Server should log server start and shutdown time to derby.log

[ http://issues.apache.org/jira/browse/DERBY-515?page=comments#action_12366973 ] Bryan Pendleton commented on DERBY-515: --- Yes, that sounds like a fine idea. Once I am fully set up, I will review and commit this change. > Network Server should log se

[jira] Updated: (DERBY-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)

[ http://issues.apache.org/jira/browse/DERBY-428?page=all ] Bryan Pendleton updated DERBY-428: -- Attachment: b428.java derby-428.diff Attached is a standalone test program, b428.java, for experimenting with the bug, and a patch proposal,

[jira] Updated: (DERBY-428) NetworkClient PreparedStatement.executeBatch() hangs if batch is too large (ArrayIndexOutOfBoundsException in Network Server)

[ http://issues.apache.org/jira/browse/DERBY-428?page=all ] Bryan Pendleton updated DERBY-428: -- Other Info: [Patch available] > NetworkClient PreparedStatement.executeBatch() hangs if batch is too large > (ArrayIndexOutOfBoundsException in Network Serv

[jira] Commented: (DERBY-515) Network Server should log server start and shutdown time to derby.log

[ http://issues.apache.org/jira/browse/DERBY-515?page=comments#action_12367681 ] Bryan Pendleton commented on DERBY-515: --- Committed derby-515-patch2-v1.diff to the trunk as revision 380722. http://svn.apache.org/viewcvs?rev=380722&view=rev This was my

[jira] Resolved: (DERBY-515) Network Server should log server start and shutdown time to derby.log

[ http://issues.apache.org/jira/browse/DERBY-515?page=all ] Bryan Pendleton resolved DERBY-515: --- Resolution: Fixed > Network Server should log server start and shutdown time to derby.log > --

[jira] Updated: (DERBY-515) Network Server should log server start and shutdown time to derby.log

[ http://issues.apache.org/jira/browse/DERBY-515?page=all ] Bryan Pendleton updated DERBY-515: -- Other Info: (was: [Patch available]) > Network Server should log server start and shutdown time to derby.log >

[jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[ http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12367758 ] Bryan Pendleton commented on DERBY-809: --- Hi Kristian, I think maybe there is one more place that needs to be changed, around line 65 of NetworkServerControl.java, where

[jira] Commented: (DERBY-952) DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin

[ http://issues.apache.org/jira/browse/DERBY-952?page=comments#action_12367770 ] Bryan Pendleton commented on DERBY-952: --- Are there any clues or theories abut this problem? I tried running with a similar, but not identical, environment, and failed to

[jira] Commented: (DERBY-965) DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network client

[ http://issues.apache.org/jira/browse/DERBY-965?page=comments#action_12367775 ] Bryan Pendleton commented on DERBY-965: --- I read through your changes and they seem good to me. It would be nice to have comments in metadata_net.properties explaining the

[jira] Commented: (DERBY-1045) forupdate.sql , holdCursorIJ.sql ..etc are failing when run with 10.1 client againest trunk

[ http://issues.apache.org/jira/browse/DERBY-1045?page=comments#action_12367840 ] Bryan Pendleton commented on DERBY-1045: Are we talking about the diff in lang/forupdate.sql which reads: 59 del < ERROR (no SQLState): Invalid cursor name "C1" in the

[jira] Updated: (DERBY-952) DerbyNet/derbynetmats/NSinSameJVM fails on Win XP / Cygwin

[ http://issues.apache.org/jira/browse/DERBY-952?page=all ] Bryan Pendleton updated DERBY-952: -- Attachment: derby-952-idea.diff Another possible way to solve this would be to let the system pick a free port number to use. That way, we wouldn't have to

[jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[ http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12367977 ] Bryan Pendleton commented on DERBY-809: --- Patch DERBY-809-1b-javadoc.diff submitted as revision 381375 http://svn.apache.org/viewcvs?rev=381375&view=rev Note that this is

[jira] Updated: (DERBY-668) SysInfo does not print the right information when Derby is not loaded through the classpath.

[ http://issues.apache.org/jira/browse/DERBY-668?page=all ] Bryan Pendleton updated DERBY-668: -- Attachment: sysinfo_Feb27_2006.diff Here's another version of the patch for review. The primary difference between this version and the previous 30-Nov-2005

[jira] Commented: (DERBY-668) SysInfo does not print the right information when Derby is not loaded through the classpath.

[ http://issues.apache.org/jira/browse/DERBY-668?page=comments#action_12368214 ] Bryan Pendleton commented on DERBY-668: --- Regarding Dan's most recent comment, about the Windows-specific path formatting, the suggestion does not seem to work for me, unf

[jira] Updated: (DERBY-668) SysInfo does not print the right information when Derby is not loaded through the classpath.

[ http://issues.apache.org/jira/browse/DERBY-668?page=all ] Bryan Pendleton updated DERBY-668: -- Attachment: sysinfo_Feb28_2006.diff Sysinfo_Feb28_2006.diff is a revised version of the sysinfo patch proposal incorporating comments from reviewers. There

[jira] Commented: (DERBY-444) Handle OutOfMemoryError exceptions when creating a new embedded connection

[ http://issues.apache.org/jira/browse/DERBY-444?page=comments#action_12368805 ] Bryan Pendleton commented on DERBY-444: --- I'm not sure I'm following the basic thrust of this. Is there something special about the Connection object? Couldn't we just as

[jira] Commented: (DERBY-708) Client driver truncates database names with spaces

[ http://issues.apache.org/jira/browse/DERBY-708?page=comments#action_12368956 ] Bryan Pendleton commented on DERBY-708: --- Is tihs a duplicate of DERBY-618? > Client driver truncates database names with spaces >

[jira] Commented: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12368965 ] Bryan Pendleton commented on DERBY-889: --- I'm not quite sure I understand what reason there is to believe that the client code is wrong here. Why is 1900-01-01 incorrect?

[jira] Assigned: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=all ] Bryan Pendleton reassigned DERBY-889: - Assign To: Bryan Pendleton > with client getTimestamp on a TIME column will print the date 1900-01-01 > instead of the current date > ---

[jira] Assigned: (DERBY-349) setByte() with executeBatch causes hang with client if mapping is invalid, e.g. setByte to DATE

[ http://issues.apache.org/jira/browse/DERBY-349?page=all ] Bryan Pendleton reassigned DERBY-349: - Assign To: Bryan Pendleton > setByte() with executeBatch causes hang with client if mapping is invalid, > e.g. setByte to DATE > -

[jira] Commented: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369162 ] Bryan Pendleton commented on DERBY-889: --- Returning the current date makes sense, and it seems like a simple change to DateTime.timeBytesToTimestamp() should be able to ac

[jira] Commented: (DERBY-349) setByte() with executeBatch causes hang with client if mapping is invalid, e.g. setByte to DATE

[ http://issues.apache.org/jira/browse/DERBY-349?page=comments#action_12369163 ] Bryan Pendleton commented on DERBY-349: --- I tried re-enabling the test code in parameterMapping.java, and the result was that I did *not* get a hang, but rather got a bliz

[jira] Commented: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369352 ] Bryan Pendleton commented on DERBY-889: --- EmbedResultSet extends ConnectionChild. ConnectionChild has a private field "cal" of type Calendar which it re-uses from call to

[jira] Commented: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369591 ] Bryan Pendleton commented on DERBY-889: --- The JCC driver has the same behavior as the Network Client driver: it prints 1900-01-01 for the date portion. > with client get

[jira] Updated: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=all ] Bryan Pendleton updated DERBY-889: -- Attachment: derby-889.diff Here is a proposed patch, including changes to both the embedded driver and the network client driver, and a regression test. Fo

[jira] Assigned: (DERBY-666) Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock

[ http://issues.apache.org/jira/browse/DERBY-666?page=all ] Bryan Pendleton reassigned DERBY-666: - Assign To: (was: Bryan Pendleton) I'm not actively working on this. There were two problems with the solution I was pursuing: 1) It required JDK 1

[jira] Assigned: (DERBY-745) DRDA Protocol Exception using DB2JCC driver and CLOBs from IJ

[ http://issues.apache.org/jira/browse/DERBY-745?page=all ] Bryan Pendleton reassigned DERBY-745: - Assign To: (was: Bryan Pendleton) I'm unassigning myself from this problem because I think the next step has to be taken by somebody who has acces

[jira] Commented: (DERBY-889) with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date

[ http://issues.apache.org/jira/browse/DERBY-889?page=comments#action_12369883 ] Bryan Pendleton commented on DERBY-889: --- > the cal field can be set by other calls I am continuing to struggle with the requirements for this issue, I'm afraid. The Res

[jira] Updated: (DERBY-668) SysInfo does not print the right information when Derby is not loaded through the classpath.

[ http://issues.apache.org/jira/browse/DERBY-668?page=all ] Bryan Pendleton updated DERBY-668: -- Attachment: with_andrews_feedback.diff Patch "with_andrews_feedback.diff" incorporates the suggestions from Andrew's review of March 8 (thanks Andrew): - T

[jira] Commented: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.

[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370217 ] Bryan Pendleton commented on DERBY-1080: I intend to submit this patch today. If any reviewers are still looking at it, please let me know. > Connection reset when u

[jira] Updated: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.

[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ] Bryan Pendleton updated DERBY-1080: --- Attachment: derby-1080-testSecMec.tmp Sunitha, I had a strange failure in testSecMec in the DerbyNet framework. This is on Linux, using Sun JDK 1.4, when

[jira] Updated: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.

[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ] Bryan Pendleton updated DERBY-1080: --- Attachment: testSecMec_with_prints.tmp testSecMec.DerbyNet.shutdown.std.log_with_prints The bug reproduces with the print statements in pl

[jira] Updated: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.

[ http://issues.apache.org/jira/browse/DERBY-1080?page=all ] Bryan Pendleton updated DERBY-1080: --- Attachment: premature_shutdown_derby.log premature_shutdown_sysinfo.out Hi Sunitha, thanks for the updates. I agree with your analysis an

[jira] Commented: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.

[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370382 ] Bryan Pendleton commented on DERBY-1080: Sunitha, can you help me understand the purpose of the Thread.sleep(5000) line in testSecMec.java? If I change that line from

[jira] Commented: (DERBY-1080) Connection reset when using security mechanism=EUSRIDPWD results in protocol error.

[ http://issues.apache.org/jira/browse/DERBY-1080?page=comments#action_12370398 ] Bryan Pendleton commented on DERBY-1080: Patch derby1080.2.diff.txt committed as Revision 385857: http://svn.apache.org/viewcvs?rev=385857&view=rev We will address the

[jira] Commented: (DERBY-1114) derbynet/testSecMec.java fails intermittently and test exits mysteriously when server is shutdown as part of the testrun.

[ http://issues.apache.org/jira/browse/DERBY-1114?page=comments#action_12370431 ] Bryan Pendleton commented on DERBY-1114: I can still reproduce the problem even with your changes to remove the switchable streams. So that's one piece of evidence tha

<    1   2   3   4   5   6   7   8   9   10   >