[jira] Updated: (DERBY-3781) PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3781: --- Derby Info: (was: [Patch Available]) Committed 'derby-3781-2b-remove_convenience_link.diff' to trunk with revision 677281. Will backport both fixes tomorrow if my test runs are successful. > PositionedStoreStream.reposition(pos) with pos greater than length leaves the > stream object in an inconsistent state > > > Key: DERBY-3781 > URL: https://issues.apache.org/jira/browse/DERBY-3781 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Fix For: 10.5.0.0 > > Attachments: derby-3781-1a-fix_and_test.diff, > derby-3781-2a-remove_convenience_link.diff, > derby-3781-2b-remove_convenience_link.diff > > > PositionedStoreStream.reposition(pos) with pos greater than the stream length > leaves the stream object in an inconsistent state, causing subsequent calls > to fail or the state to remain inconsistent (which can cause the wrong data > to be returned). > The problem is that the position variable gets out of sync with the > underlying stream. > There are at least two ways to fix this (assuming the positioned store stream > does not know the length of the underlying stream): > a) Reset stream to position zero. > b) Let the stream be positioned at EOF and update the internal position > variable. > Option b) leaves the stream in an unusable state, and the next request will > cause option a) to be performed. It also require a slight rewrite of > 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to > be able to determine the position of the stream (the length in this case). > Option a) will cause the first page of the stream to be read into the cache > (if not already there), but taken the reason for doing this is an error > condition it seems acceptable. > A correct value of the position variable is required for correct/valid > operation of PositionedStoreStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3781) PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3781: --- Attachment: derby-3781-2b-remove_convenience_link.diff Attached 'derby-3781-2b-remove_convenience_link.diff', which removes the instanceof check. Knut Anders wrote: - Perhaps it would be better to use ASSERT instead of IllegalArgumentException? Then we don't need to worry about the risk of presenting non-localized error messages to the users, or about increasing the footprint of the production jars. The error won't be hidden in production code, it'll just happen another place, and I think it'll still be fairly easy to see what the problem is from the ClassCastException that will be presented. - After analyzing the code, I've decided to remove the check. It is already checked elsewhere (EmbedBlob and EmbedClob) in sane builds, and it will fail with a CCE during initStream if an invalid stream is passed in from somewhere else in the future in the insane builds. - Another thing I came to think about - is it possible to expose the original problem through JDBC? - Yes, and it's already being done through BlobClob4BlobTest.testGetBytes. It should be easy to write a more specific test to make it more explicit. Are you happy with the existing test, or should I write a specific regression test for the Jira? > PositionedStoreStream.reposition(pos) with pos greater than length leaves the > stream object in an inconsistent state > > > Key: DERBY-3781 > URL: https://issues.apache.org/jira/browse/DERBY-3781 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Fix For: 10.5.0.0 > > Attachments: derby-3781-1a-fix_and_test.diff, > derby-3781-2a-remove_convenience_link.diff, > derby-3781-2b-remove_convenience_link.diff > > > PositionedStoreStream.reposition(pos) with pos greater than the stream length > leaves the stream object in an inconsistent state, causing subsequent calls > to fail or the state to remain inconsistent (which can cause the wrong data > to be returned). > The problem is that the position variable gets out of sync with the > underlying stream. > There are at least two ways to fix this (assuming the positioned store stream > does not know the length of the underlying stream): > a) Reset stream to position zero. > b) Let the stream be positioned at EOF and update the internal position > variable. > Option b) leaves the stream in an unusable state, and the next request will > cause option a) to be performed. It also require a slight rewrite of > 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to > be able to determine the position of the stream (the length in this case). > Option a) will cause the first page of the stream to be read into the cache > (if not already there), but taken the reason for doing this is an error > condition it seems acceptable. > A correct value of the position variable is required for correct/valid > operation of PositionedStoreStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3781) PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3781: --- Attachment: derby-3781-2a-remove_convenience_link.diff 'derby-3781-2a-remove_convenience_link.diff' removes the convenience link and replaces it with casts in three places. I also added a instanceof check in the constructor to detect where in the code an invalid stream might be passed in. I think it is better to catch the error where it originates instead of waiting for a ClassCastException at a later point in time. Patch ready for review. > PositionedStoreStream.reposition(pos) with pos greater than length leaves the > stream object in an inconsistent state > > > Key: DERBY-3781 > URL: https://issues.apache.org/jira/browse/DERBY-3781 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Fix For: 10.5.0.0 > > Attachments: derby-3781-1a-fix_and_test.diff, > derby-3781-2a-remove_convenience_link.diff > > > PositionedStoreStream.reposition(pos) with pos greater than the stream length > leaves the stream object in an inconsistent state, causing subsequent calls > to fail or the state to remain inconsistent (which can cause the wrong data > to be returned). > The problem is that the position variable gets out of sync with the > underlying stream. > There are at least two ways to fix this (assuming the positioned store stream > does not know the length of the underlying stream): > a) Reset stream to position zero. > b) Let the stream be positioned at EOF and update the internal position > variable. > Option b) leaves the stream in an unusable state, and the next request will > cause option a) to be performed. It also require a slight rewrite of > 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to > be able to determine the position of the stream (the length in this case). > Option a) will cause the first page of the stream to be read into the cache > (if not already there), but taken the reason for doing this is an error > condition it seems acceptable. > A correct value of the position variable is required for correct/valid > operation of PositionedStoreStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3781) PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3781: --- Fix Version/s: 10.5.0.0 Committed 'derby-3781-1a-fix_and_test.diff' to trunk with revision 677172. > PositionedStoreStream.reposition(pos) with pos greater than length leaves the > stream object in an inconsistent state > > > Key: DERBY-3781 > URL: https://issues.apache.org/jira/browse/DERBY-3781 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Fix For: 10.5.0.0 > > Attachments: derby-3781-1a-fix_and_test.diff > > > PositionedStoreStream.reposition(pos) with pos greater than the stream length > leaves the stream object in an inconsistent state, causing subsequent calls > to fail or the state to remain inconsistent (which can cause the wrong data > to be returned). > The problem is that the position variable gets out of sync with the > underlying stream. > There are at least two ways to fix this (assuming the positioned store stream > does not know the length of the underlying stream): > a) Reset stream to position zero. > b) Let the stream be positioned at EOF and update the internal position > variable. > Option b) leaves the stream in an unusable state, and the next request will > cause option a) to be performed. It also require a slight rewrite of > 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to > be able to determine the position of the stream (the length in this case). > Option a) will cause the first page of the stream to be read into the cache > (if not already there), but taken the reason for doing this is an error > condition it seems acceptable. > A correct value of the position variable is required for correct/valid > operation of PositionedStoreStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3781) PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3781: --- Derby Info: [Patch Available] > PositionedStoreStream.reposition(pos) with pos greater than length leaves the > stream object in an inconsistent state > > > Key: DERBY-3781 > URL: https://issues.apache.org/jira/browse/DERBY-3781 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Attachments: derby-3781-1a-fix_and_test.diff > > > PositionedStoreStream.reposition(pos) with pos greater than the stream length > leaves the stream object in an inconsistent state, causing subsequent calls > to fail or the state to remain inconsistent (which can cause the wrong data > to be returned). > The problem is that the position variable gets out of sync with the > underlying stream. > There are at least two ways to fix this (assuming the positioned store stream > does not know the length of the underlying stream): > a) Reset stream to position zero. > b) Let the stream be positioned at EOF and update the internal position > variable. > Option b) leaves the stream in an unusable state, and the next request will > cause option a) to be performed. It also require a slight rewrite of > 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to > be able to determine the position of the stream (the length in this case). > Option a) will cause the first page of the stream to be read into the cache > (if not already there), but taken the reason for doing this is an error > condition it seems acceptable. > A correct value of the position variable is required for correct/valid > operation of PositionedStoreStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3781) PositionedStoreStream.reposition(pos) with pos greater than length leaves the stream object in an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3781: --- Attachment: derby-3781-1a-fix_and_test.diff 'derby-3781-1a-fix_and_test.diff' fixes the bug by resetting the stream after an unsuccessful reposition attempt. Also includes a regression test. I ran all tests without failures, but due to a last minute change in the patch I'm rerunning. Patch ready for review. > PositionedStoreStream.reposition(pos) with pos greater than length leaves the > stream object in an inconsistent state > > > Key: DERBY-3781 > URL: https://issues.apache.org/jira/browse/DERBY-3781 > Project: Derby > Issue Type: Bug > Components: Store >Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0 >Reporter: Kristian Waagan >Assignee: Kristian Waagan >Priority: Minor > Attachments: derby-3781-1a-fix_and_test.diff > > > PositionedStoreStream.reposition(pos) with pos greater than the stream length > leaves the stream object in an inconsistent state, causing subsequent calls > to fail or the state to remain inconsistent (which can cause the wrong data > to be returned). > The problem is that the position variable gets out of sync with the > underlying stream. > There are at least two ways to fix this (assuming the positioned store stream > does not know the length of the underlying stream): > a) Reset stream to position zero. > b) Let the stream be positioned at EOF and update the internal position > variable. > Option b) leaves the stream in an unusable state, and the next request will > cause option a) to be performed. It also require a slight rewrite of > 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to > be able to determine the position of the stream (the length in this case). > Option a) will cause the first page of the stream to be read into the cache > (if not already there), but taken the reason for doing this is an error > condition it seems acceptable. > A correct value of the position variable is required for correct/valid > operation of PositionedStoreStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
