[
https://issues.apache.org/jira/browse/PHOENIX-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852473#comment-15852473
]
Poorna Chandra commented on PHOENIX-3585:
-----------------------------------------
[~jamestaylor] Looking at the javadocs for the following {{RegionObserver}}
method -
{code}
InternalScanner preCompactScannerOpen(final
ObserverContext<RegionCoprocessorEnvironment> c,
final Store store, List<? extends KeyValueScanner> scanners, final
ScanType scanType,
final long earliestPutTs, final InternalScanner s, CompactionRequest
request)
{code}
I understand that if {{InternalScanner s}} is not null, then it is the scanner
returned by the previous RegionObserver in the chain. In that case should the
TransactionProcessor just apply the filter to the internal scanner and ignore
the store scanners {{List<? extends KeyValueScanner> scanners}}?
I think the filtering code in TransactionProcessor was written expecting
TransactionProcessor to be the first co-processor in the chain, so that it can
filter out in-progress and invalid transactions before any other co-processor
in the chain. If I understand this issue correctly, it seems that there is a
Phoenix co-processor before TransactionProcessor in the chain. It will be
useful if you can explain the reason for the Phoenix co-processor appearing
early in the chain.
> MutableIndexIT testSplitDuringIndexScan and testIndexHalfStoreFileReader fail
> for transactional tables and local indexes
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3585
> URL: https://issues.apache.org/jira/browse/PHOENIX-3585
> Project: Phoenix
> Issue Type: Bug
> Reporter: Thomas D'Silva
> Assignee: Thomas D'Silva
> Attachments: diff.patch
>
>
> the tests fail if we use HDFSTransactionStateStorage instead of
> InMemoryTransactionStateStorage when we create the TransactionManager in
> BaseTest
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
