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 "Sunitha Kambhampati (JIRA)" <de...@db.apache.org> on 2005/10/02 04:27:49 UTC
[jira] Created: (DERBY-595) Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
-------------------------------------------------------------------------------------------------------------------
Key: DERBY-595
URL: http://issues.apache.org/jira/browse/DERBY-595
Project: Derby
Type: Bug
Components: SQL
Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
Environment: all
Reporter: Sunitha Kambhampati
Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
See
1)in GenericParameter.toString()
try
{
return value.getString();
}
catch (StandardException se)
{
return "unexpected exception from getString() - " + se;
}
}
2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
________
Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and you can use the test fails and the exception wont be thrown for the error cases.
I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true property set. I'll file another bug to resolve this test.
--
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
Re: [jira] Created: (DERBY-595) Using derby.language.logStatementText=true
can mask certain exceptions and lead to incorrect behavior in some cases
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Kathey Marsden wrote:
>Sunitha Kambhampati wrote:
>
>
>
>>As an aside, should we be printing out the paramter values (that are
>>set using streams) in derby.log when
>>derby.language.logStatementText=true.? We can run out of memory if
>>this property is enabled as it will print out the string values to
>>derby.log.
>>Should we advise users to not use this property when setting really
>>large parameter values...
>>
>>Thoughts/comments.
>>
>>
>>
>We rely very heavily on this property to diagnose user issues. I don't
>think it is good to have any configuration where we should not set
>it or might hit memory problems if we do. I think it would be fine just
>to print the stream objects to string value, giving us the class and
>hashcode for stream parameters.
>
>
>
>
I agree, Kathey. I opened a jira improvement DERBY-598 for this.
Thanks,
Sunitha.
Re: [jira] Created: (DERBY-595) Using derby.language.logStatementText=true
can mask certain exceptions and lead to incorrect behavior in some cases
Posted by Kathey Marsden <km...@sbcglobal.net>.
Sunitha Kambhampati wrote:
> As an aside, should we be printing out the paramter values (that are
> set using streams) in derby.log when
> derby.language.logStatementText=true.? We can run out of memory if
> this property is enabled as it will print out the string values to
> derby.log.
> Should we advise users to not use this property when setting really
> large parameter values...
>
> Thoughts/comments.
>
We rely very heavily on this property to diagnose user issues. I don't
think it is good to have any configuration where we should not set
it or might hit memory problems if we do. I think it would be fine just
to print the stream objects to string value, giving us the class and
hashcode for stream parameters.
Kathey
Re: [jira] Created: (DERBY-595) Using derby.language.logStatementText=true
can mask certain exceptions and lead to incorrect behavior in some cases
Posted by Sunitha Kambhampati <ks...@gmail.com>.
As an aside, should we be printing out the paramter values (that are set
using streams) in derby.log when
derby.language.logStatementText=true.? We can run out of memory if this
property is enabled as it will print out the string values to derby.log.
Should we advise users to not use this property when setting really
large parameter values...
Thoughts/comments.
Thanks,
Sunitha.
Sunitha Kambhampati (JIRA) wrote:
>Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
>-------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: http://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
> Environment: all
> Reporter: Sunitha Kambhampati
>
>
>Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
>
>I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
>
>See
>1)in GenericParameter.toString()
>try
>{
>return value.getString();
>}
>catch (StandardException se)
>{
>return "unexpected exception from getString() - " + se;
>}
>}
>
>2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
>________
>
>Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and you can use the test fails and the exception wont be thrown for the error cases.
>
>
>I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true property set. I'll file another bug to resolve this test.
>
>
>
[jira] Updated: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-595:
----------------------------------
Derby Info: (was: [Patch Available])
Committed 'derby595_v2.diff' to trunk with revision 529983.
Ran suites.All (JDK 1.5) without failures. Running derbyall and suites.All with JDK 1.6 as we speak.
Will report back when done and look at merging the fix with the 10.2 branch.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff, derby595_v2.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mayuresh Nirhali resolved DERBY-595.
------------------------------------
Resolution: Fixed
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff, derby595_v2.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479234 ]
Mayuresh Nirhali commented on DERBY-595:
----------------------------------------
After some debugging, I found that the call to getString returns the Exception as a String and, more importantly, leaves the DVD in inconsistent state. Here is why.
The logging code calls the getTraceString to identify the data length. In case of Streams, such objects are fully read when getString is called populating a DVD object. So, after the statement logging is done, the object is treated as DVD itself and not a stream, So the expected exception would not occur.
Now, currently In the current statement logging code, the exception is returned as a String so it is thrown properly to the user.
For the specific case of input stream having too few bytes (less bytes actually on stream than expected), the DVD that is populated is not in consistent state. This is because the java.io.DataInputStream will read until input data is available, end of file is detected, or an exception occurs. As the bytes available are fewer than expected the DIStream will believe that there are some more bytes to be read even after reading the available bytes. This next read call returns -1 and puts the DVD in invalid state.
So, eating up the Exception in the logging code does not seem to work.
Only 2 options come to my mind, at this point.
1. Handle the Exception properly in the statement logging code, so that any errors in the stream object will be properly notified to the user.
2. Defer full read of stream until statement logging is complete. During statement logging only provide expected length of the stream. This behavior will be exactly same as the behavior when logStatementText is FALSE in terms of when the stream is fully read.
I would appreciate experts' opinion here... and please let me know if there is any other way this bug can be fixed.
TIA
Mayuresh
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mayuresh Nirhali updated DERBY-595:
-----------------------------------
Attachment: derby595_v2.diff
Kristian, I have tried to address your comments in this next patch.
Instead of classname, I am now using getTypeName(). This seems to be the best choice which I should have got to sooner. :)
Also, the getTraceString method in SQLChar is not final now, it will call toString method so that the actual values for char/varchar are populated. I am keeping the getTraceString() method from SQLClob as per the derby1693 fix, but with minor changes.
I have ran the tests which showed problems and also 1693 repro case.
I will run the regression tests tomorrow.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff, derby595_v2.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12488036 ]
Kristian Waagan commented on DERBY-595:
---------------------------------------
I had a look at the patch and have a few comments.
I am not sure I like the class name for the column type. This might be okay for developers, but for users reading the log they provide little use. Could we use the SQL type instead?
We could also consider another representation for the streams, but I can't think of any good ones except for possibly removing the package names. The memory location could be useful during debugging.
Here is an example of the log when inserting a CLOB with a stream and a string of length eight into a VARCHAR column:
2007-04-11 09:20:08.854 GMT Thread[main,5,main] (XID = 3400), (SESSIONID = 0), (DATABASE = ReproDerby1693DB), (DRDAID = null), Executing prepared statement: insert into clobs values (?) :End prepared statement with 1 parameters begin parameter #1: class org.apache.derby.iapi.types.SQLClob(org.apache.derby.iapi.types.ReaderToUTF8Stream@19ce060) :end parameter
2007-04-11 09:20:14.587 GMT Thread[main,5,main] (XID = 5010), (SESSIONID = 0), (DATABASE = ReproDerby1693DB), (DRDAID = null), Executing prepared statement: insert into varchars values (?) :End prepared statement with 1 parameters begin parameter #1: class org.apache.derby.iapi.types.SQLVarchar:Length=8 :end parameter
Next, I like to see the actual values in the log for types where this is "suitable". The problem is defining what is suitable. Any VARCHAR up to the maximum length? If the length of the string is less than N? Just for string types, not binary?
I believe the patch do change the behavior. Where strings (CHAR, VARCHAR) were printed earlier, there will now be a class name and a length.
I hope someone else can express their opinions on these issues.
Last, there are a few whitespace issues I'd like to see fixed, but I believe they can be handled on commit if necessary. I like to have a blank line between methods (last line of previous method and the JavaDoc/signature of the next), and also spaces in string constructions. You may ignore these as my personal likings, but I mention them because I mean they improve the readability of the code.
Thanks,
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mayuresh Nirhali reassigned DERBY-595:
--------------------------------------
Assignee: Mayuresh Nirhali
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489677 ]
Mayuresh Nirhali commented on DERBY-595:
----------------------------------------
derbyall and junit tests passed.
Patch is ready for review!!
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff, derby595_v2.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mayuresh Nirhali updated DERBY-595:
-----------------------------------
Attachment: derby595.diff
Attaching patch for review with this comment.
The implementation of getTraceString methods has been moved from SQLBlob, SQLClob to SQLBinary, SQLChar respectively with minor modifications. This will ensure that Character/Binary stream associated with subtypes of SQLBinary and SQLChar will not be drained in logStatementText=true mode.
As for the text written in the log, the class name of the SQLType will be printed along with stream object. I would like to know if printing the class name is okay ??
Also, as mentioned in 1693, if the Object does not have stream associated with it, only the classname and its length is printed in log. This behavior will remain as is even after this fix. This will now be applicable to almost all the types, so I would like to know specific comments on this from someone who is more familiar with this part of the code.
The failing tests, jdbcapi/resultsetStream.java, lang/CharasterStreamsTest now pass with logStatementText=true. The Repro for 1693 also passes.
Derbyall and Suites.All ran clean.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Attachments: derby595.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-595:
----------------------------------
Affects Version/s: 10.3.0.0
10.2.1.6
Hello Mayuresh,
I had a look at this. It seems DERBY-1693 fixed this problem for [BC]lob, but not for other data types. The fix was too specific/narrow (sorry 'bout that...).
One way to fix this, would be to implement a mechanism similar to what is found in SQLClob.getTraceString for all data types that can be set from a stream (or where draining the stream would cause problems). I do not know if there is a single point of interception for this, or if we must implement the method in each appropriate data type. It might also depend on whether we want to include the name of the data type in the trace string.
I would suggest having a look at the type hierarchy in 'iapi.types' and see if a clear solution stands out.
The current intent of getTraceString for streamable types, is to not drain the stream if the data is represented as a stream. Obtaining length information in this case is not feasible. One must also consider if the data itself should be printed to the log, or only the length. For Clob, "CLOB(32453)" is printed if the data is materialized, "CLOB(some.kind.of.stream.Class@15f4a7f)" otherwise.
When I applied a temporary fix to SQLLongVarbit, 'resultsetStream' passed with statement logging enabled.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan closed DERBY-595.
---------------------------------
Closing issue.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.1.4
> Environment: all
> Reporter: Sunitha Kambhampati
> Assignee: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.1.4
>
> Attachments: derby595.diff, derby595_v2.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486316 ]
Mayuresh Nirhali commented on DERBY-595:
----------------------------------------
Thanks Kristian.
I agree with you that implementing getTraceString will solve the problem of not draining out the stream when logStatementText is true.
On my investigation to identify which SQL types will be affected by this, I found out that jdbcapi/CharacterStreamsTest also fails due to same problem with logStatementText=true. This particular test uses 4 types, SQLChar, SQLVarChar, SQLLongVarchar, SQLClob and the test failed for 3 types (except SQLClob due to fix for 1683). I tried moving the getTraceString implementation from SQLClob to SQLChar and the test passed.
Currently, I am running all the tests with logStatementText = true (on a fresh sandbox). This will present a clear and complete picture of 595.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-595) Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-595?page=all ]
Sunitha Kambhampati updated DERBY-595:
--------------------------------------
Description:
Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
See
1)in GenericParameter.toString()
try
{
return value.getString();
}
catch (StandardException se)
{
return "unexpected exception from getString() - " + se;
}
}
2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
________
Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
was:
Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
See
1)in GenericParameter.toString()
try
{
return value.getString();
}
catch (StandardException se)
{
return "unexpected exception from getString() - " + se;
}
}
2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
________
Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and you can use the test fails and the exception wont be thrown for the error cases.
I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true property set. I'll file another bug to resolve this test.
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: http://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
> Environment: all
> Reporter: Sunitha Kambhampati
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
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-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12494202 ]
Kristian Waagan commented on DERBY-595:
---------------------------------------
Merged fix ('derby595_v2.diff') to 10.2 with revision 536104.
Ran derbyall without failures (1.6).
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff, derby595_v2.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Bryan Pendleton (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-595?page=comments#action_12461512 ]
Bryan Pendleton commented on DERBY-595:
---------------------------------------
I notice that DERBY-1693 has added a getTraceString() method to DataValueDescriptor.
Does that make it easier to fix this bug? Could we, for example, arrange it so that
exceptions from getTraceString were safe to swallow in the logging code, but exceptions
from getString would still show through to the user?
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: http://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.1.1.0, 10.0.2.1
> Environment: all
> Reporter: Sunitha Kambhampati
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
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-595) Using
derby.language.logStatementText=true can mask certain exceptions and lead
to incorrect behavior in some cases
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mayuresh Nirhali updated DERBY-595:
-----------------------------------
Derby Info: [Patch Available]
Fix Version/s: 10.3.0.0
10.2.3.0
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior in some cases
> -------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-595
> URL: https://issues.apache.org/jira/browse/DERBY-595
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.1.6, 10.3.0.0
> Environment: all
> Reporter: Sunitha Kambhampati
> Assigned To: Mayuresh Nirhali
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: derby595.diff
>
>
> Using derby.language.logStatementText=true can mask certain exceptions and lead to incorrect behavior.
> I observed this with tests using streams, where if valid (expected) exceptions are raised when DVD.getString() is called, the exception gets eaten up when this property is set.
> See
> 1)in GenericParameter.toString()
> try
> {
> return value.getString();
> }
> catch (StandardException se)
> {
> return "unexpected exception from getString() - " + se;
> }
> }
> 2)in GenericPreparedStatement.execute(), where pvs.toString() is called for the parameters.
> ________
> Reproduction: Run the test jdbcapi/resultsetStream.java , with derby.language.logStatementText=true and expected error exceptions wont be thrown for the error cases.
> I looked at the tests that use streams , only the store/streamingColumn.java uses derby.language.logStatementText=true. I'll file another bug to resolve this test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.