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