[jira] [Resolved] (ACCUMULO-3339) Replace SortedMap from Tablet constructor
[ https://issues.apache.org/jira/browse/ACCUMULO-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Newton resolved ACCUMULO-3339. --- Resolution: Fixed > Replace SortedMap from Tablet constructor > - > > Key: ACCUMULO-3339 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3339 > Project: Accumulo > Issue Type: Improvement > Components: tserver >Reporter: Josh Elser >Assignee: Eric Newton > Fix For: 1.8.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The TabletServer reads the metadata table and places the Key Value pairs for > the given tablet into a SortedMap which it passes to the Tablet constructor. > Tablet then has a bunch of custom code which extracts out the log entries, > data files, time, last location, scan files, etc. > All of that could be encapsulated into its own classes instead of extra > methods on Tablet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616928#comment-14616928
]
Eric Newton commented on ACCUMULO-3931:
---
The thread pool for the BatchScanner is shared among all the iterators created
from that scanner.
So, if the iterators don't read the results, the fetching threads will block,
which makes it impossible to learn if there is a next.
The work around is to create a new BatchScanner each time in the client (more
threads) or read the results after checking hasNext, freeing the threads to
work for the other iterators.
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Newton resolved ACCUMULO-3931.
---
Resolution: Not A Problem
Feel free to open a new ticket to enhance the BatchScanner to have a different
behavior.
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616951#comment-14616951
]
Josh Elser commented on ACCUMULO-3931:
--
bq. The work around is to create a new BatchScanner each time in the client
(more threads) or read the results after checking hasNext, freeing the threads
to work for the other iterators.
Maybe some better javadoc on {{iterator()}} or the class itself would be
helpful in reminding users (and ourselves) of this in the future? What do you
think?
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ACCUMULO-3933) parent issue broke VolumeIT
Eric Newton created ACCUMULO-3933: - Summary: parent issue broke VolumeIT Key: ACCUMULO-3933 URL: https://issues.apache.org/jira/browse/ACCUMULO-3933 Project: Accumulo Issue Type: Sub-task Components: tserver Reporter: Eric Newton Fix For: 1.8.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616992#comment-14616992
]
Eric Newton commented on ACCUMULO-3931:
---
The {{iterator()}} method is in {{ScannerBase}}, so it's confusing to talk
about threads at that level. Maybe a note on {{Connector#createBatchScanner}}?
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ACCUMULO-3934) Improve documentation about multiple calls to iterator() sharing threads on single BatchScanner
Josh Elser created ACCUMULO-3934:
Summary: Improve documentation about multiple calls to iterator()
sharing threads on single BatchScanner
Key: ACCUMULO-3934
URL: https://issues.apache.org/jira/browse/ACCUMULO-3934
Project: Accumulo
Issue Type: Sub-task
Components: client, docs
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Minor
Fix For: 1.6.4, 1.7.1, 1.8.0
After digging into ACCUMULO-3931, [~ecn] realized that multiple calls to
{{iterator()}} on a BatchScanner would all be sharing threads on the same
ThreadPool which would ultimately lead to starvation.
Add some documentation to try to make it clear that multiple calls to
{{iterator()}} on a {{BatchScanner}} will share the same {{ThreadPool}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617010#comment-14617010
]
Josh Elser commented on ACCUMULO-3931:
--
Good point. Opened up ACCUMULO-3934 to make a docs change.
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ACCUMULO-3935) Not easy to configure server side extension using NewTableConfiguration
[
https://issues.apache.org/jira/browse/ACCUMULO-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Turner updated ACCUMULO-3935:
---
Issue Type: Improvement (was: Bug)
> Not easy to configure server side extension using NewTableConfiguration
> ---
>
> Key: ACCUMULO-3935
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3935
> Project: Accumulo
> Issue Type: Improvement
>Reporter: Keith Turner
> Fix For: 1.8.0
>
>
> Using {{NewTableConfiguration}} iterators, constraints, and locality groups
> can all be configured before a new table comes online. For existing tables
> there are convenience methods that help set the properties for these things.
> However there is no way to leverage these convenience methods with
> {{NewTableConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ACCUMULO-3935) Not easy to configure server side extension using NewTableConfiguration
Keith Turner created ACCUMULO-3935:
--
Summary: Not easy to configure server side extension using
NewTableConfiguration
Key: ACCUMULO-3935
URL: https://issues.apache.org/jira/browse/ACCUMULO-3935
Project: Accumulo
Issue Type: Bug
Reporter: Keith Turner
Fix For: 1.8.0
Using {{NewTableConfiguration}} iterators, constraints, and locality groups can
all be configured before a new table comes online. For existing tables there
are convenience methods that help set the properties for these things.
However there is no way to leverage these convenience methods with
{{NewTableConfiguration}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617041#comment-14617041
]
Russ Weeks commented on ACCUMULO-3931:
--
Thanks for looking into this!
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ACCUMULO-3936) Improvements to docs/instructions for PerformanceTests
Josh Elser created ACCUMULO-3936: Summary: Improvements to docs/instructions for PerformanceTests Key: ACCUMULO-3936 URL: https://issues.apache.org/jira/browse/ACCUMULO-3936 Project: Accumulo Issue Type: Sub-task Components: docs Reporter: Josh Elser Assignee: Josh Elser Priority: Minor Fix For: 1.8.0 Need to improve the docs a bit with clear instructions on how to run them and how to use the PerformanceTest interface with Category annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ACCUMULO-3933) parent issue broke VolumeIT
[ https://issues.apache.org/jira/browse/ACCUMULO-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Newton resolved ACCUMULO-3933. --- Resolution: Fixed > parent issue broke VolumeIT > --- > > Key: ACCUMULO-3933 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3933 > Project: Accumulo > Issue Type: Sub-task > Components: tserver >Reporter: Eric Newton > Fix For: 1.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ACCUMULO-3931) Repeated invocations of BatchScanner iterator().hasNext() causes MAC to become unresponsive
[
https://issues.apache.org/jira/browse/ACCUMULO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated ACCUMULO-3931:
Fix Version/s: (was: 1.6.4)
(was: 1.7.1)
(was: 1.8.0)
> Repeated invocations of BatchScanner iterator().hasNext() causes MAC to
> become unresponsive
> ---
>
> Key: ACCUMULO-3931
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3931
> Project: Accumulo
> Issue Type: Bug
> Components: mini
>Affects Versions: 1.6.3, 1.7.0
>Reporter: Russ Weeks
>Assignee: Eric Newton
> Attachments: tablet_server_0.txt, tablet_server_1.txt,
> test_runner_stack.txt
>
>
> Steps to reproduce:
> # Instantiate a MiniAccumuloCluster with at least two tablet servers
> # Create a table; add splits to the table.
> # Add some mutations to the table distributed across the splits; flush the
> mutations.
> # Create a BatchScanner across the full range of the table.
> # Assert that the batch scanner has at least one KV pair by calling
> {{scanner.iterator().hasNext()}}
> # Repeat.
> It doesn't seem to matter if you close the scanner and create a new one in
> between calls to hasNext, or if you re-seek the same scanner, or if the
> scanner is created in a static context and re-used by multiple tests or
> created by each test. Eventually you will see that the
> {{TabletServerBatchReaderIterator}} gets stuck polling its resultsQueue,
> preventing further tests from running.
> This happens roughyl 20% of the time in 1.6 when I run {{mvn clean test
> -Dtest=org.apache.accumulo.minicluster.MultipleHasNextTest --projects
> minicluster}}, maybe less often in 1.7, and 100% of the time when I try to
> use the MAC in my company's product build environment, which uses gradle.
> (I'll update with a link to a failing unit test as soon as I get an issue ID)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617565#comment-14617565 ] John Vines commented on ACCUMULO-3509: -- Any updates? > Scanner lock cause Tablet lock, hence preventing idle scans from being swept, > hence blocking SimpleTimer thread > > > Key: ACCUMULO-3509 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3509 > Project: Accumulo > Issue Type: Bug > Components: tserver >Affects Versions: 1.6.0 >Reporter: marco polo >Assignee: marco polo > Fix For: 1.8.0 > > > Synchronization with Tablet$Scanner via a read() will block close() being > called via the sweep method in TabletServer. As a result, the SimpleTimer > thread does not continue, and idle threads grow until the scan completes. > My patch, which is forthcoming, converts synchronized methods to use a fair > lock. If the lock is held by a read call, the close call will attempt to > obtain it, time out, and return indicating a close was not successful. The > sweep will continue, and the SimpleTimer thread will respawn later, > attempting closure on those Tablets at a later time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-2346) Make UtilWaitThread.sleep() reset interrupt status
[
https://issues.apache.org/jira/browse/ACCUMULO-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617636#comment-14617636
]
John Vines commented on ACCUMULO-2346:
--
I would also like to +1 this. I don't know of the repercussions, but currently
this can cause threads that are impossible to interrupt out, which is
infuriating. There need to be means for clients to interrupt out their threads.
> Make UtilWaitThread.sleep() reset interrupt status
> --
>
> Key: ACCUMULO-2346
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2346
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
> Fix For: 1.8.0
>
>
> Look into making UtilWaitThread.sleep() reset the interrupt status by calling
> {{Thread.currentThread().interrupt()}}. This seems like a good thing to do,
> it allows code that does not want to deal with the interrupt to pass it on.
> The question is, does doing this cause new bugs?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-2346) Make UtilWaitThread.sleep() reset interrupt status
[
https://issues.apache.org/jira/browse/ACCUMULO-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617637#comment-14617637
]
John Vines commented on ACCUMULO-2346:
--
Also, might I suggest replacing it entirely with Uninterruptibles.sleep
> Make UtilWaitThread.sleep() reset interrupt status
> --
>
> Key: ACCUMULO-2346
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2346
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
> Fix For: 1.8.0
>
>
> Look into making UtilWaitThread.sleep() reset the interrupt status by calling
> {{Thread.currentThread().interrupt()}}. This seems like a good thing to do,
> it allows code that does not want to deal with the interrupt to pass it on.
> The question is, does doing this cause new bugs?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ACCUMULO-3926) "Stream already closed" exceptions from Thrift connections
[
https://issues.apache.org/jira/browse/ACCUMULO-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated ACCUMULO-3926:
-
Assignee: (was: Josh Elser)
> "Stream already closed" exceptions from Thrift connections
> --
>
> Key: ACCUMULO-3926
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3926
> Project: Accumulo
> Issue Type: Bug
> Components: client
>Reporter: Josh Elser
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
>
> Noticed this frequently during randomwalk:
> {noformat}
> 29 05:20:17,446 [transport.TIOStreamTransport] WARN : Error closing output
> stream.
> java.io.IOException: The stream is closed
> at
> org.apache.hadoop.net.SocketOutputStream.write(SocketOutputStream.java:118)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at java.io.FilterOutputStream.close(FilterOutputStream.java:158)
> at
> org.apache.thrift.transport.TIOStreamTransport.close(TIOStreamTransport.java:110)
> at
> org.apache.thrift.transport.TFramedTransport.close(TFramedTransport.java:89)
> at
> org.apache.accumulo.core.client.impl.ThriftTransportPool$CachedTTransport.close(ThriftTransportPool.java:309)
> at
> org.apache.accumulo.core.client.impl.ThriftTransportPool.returnTransport(ThriftTransportPool.java:571)
> at
> org.apache.accumulo.core.rpc.ThriftUtil.returnClient(ThriftUtil.java:147)
> at
> org.apache.accumulo.core.client.impl.TabletServerBatchReaderIterator.doLookup(TabletServerBatchReaderIterator.java:686)
> at
> org.apache.accumulo.core.client.impl.TabletServerBatchReaderIterator$QueryTask.run(TabletServerBatchReaderIterator.java:349)
> at org.apache.htrace.wrappers.TraceRunnable.run(TraceRunnable.java:57)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ACCUMULO-3506) Create integration test for proxy running over SSL
[ https://issues.apache.org/jira/browse/ACCUMULO-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-3506: - Assignee: (was: Josh Elser) > Create integration test for proxy running over SSL > -- > > Key: ACCUMULO-3506 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3506 > Project: Accumulo > Issue Type: Sub-task > Components: proxy, test >Reporter: Josh Elser > Fix For: 1.8.0 > > > ACCUMULO-3452 indirectly added support for starting the proxy with SSL (by > virtue of leveraging the existing code). > We need to write tests to ensure that it is functional and nothing is missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ACCUMULO-3934) Improve documentation about multiple calls to iterator() sharing threads on single BatchScanner
[
https://issues.apache.org/jira/browse/ACCUMULO-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved ACCUMULO-3934.
--
Resolution: Fixed
> Improve documentation about multiple calls to iterator() sharing threads on
> single BatchScanner
> ---
>
> Key: ACCUMULO-3934
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3934
> Project: Accumulo
> Issue Type: Sub-task
> Components: client, docs
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
> Fix For: 1.6.4, 1.7.1, 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After digging into ACCUMULO-3931, [~ecn] realized that multiple calls to
> {{iterator()}} on a BatchScanner would all be sharing threads on the same
> ThreadPool which would ultimately lead to starvation.
> Add some documentation to try to make it clear that multiple calls to
> {{iterator()}} on a {{BatchScanner}} will share the same {{ThreadPool}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Accumulo-1.7 - Build # 105 - Fixed
The Apache Jenkins build system has built Accumulo-1.7 (build #105) Status: Fixed Check console output at https://builds.apache.org/job/Accumulo-1.7/105/ to view the results.
[jira] [Resolved] (ACCUMULO-3936) Improvements to docs/instructions for PerformanceTests
[ https://issues.apache.org/jira/browse/ACCUMULO-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved ACCUMULO-3936. -- Resolution: Fixed > Improvements to docs/instructions for PerformanceTests > -- > > Key: ACCUMULO-3936 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3936 > Project: Accumulo > Issue Type: Sub-task > Components: docs >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Minor > Fix For: 1.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Need to improve the docs a bit with clear instructions on how to run them and > how to use the PerformanceTest interface with Category annotation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1680) Atomic add and remove of authorizations
[
https://issues.apache.org/jira/browse/ACCUMULO-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617973#comment-14617973
]
Josh Elser commented on ACCUMULO-1680:
--
Sorry for the extreme delay in looking at this.
The patch looks good in general, but it did fail some findbugs checks.
{noformat}
[INFO] --- findbugs-maven-plugin:3.0.1:check (run-findbugs) @ accumulo-shell ---
[INFO] BugInstance size is 3
[INFO] Error size is 0
[INFO] Total bugs: 3
[INFO] The method name
org.apache.accumulo.shell.commands.DeleteAuthsCommandTest.DeleteAllAuth()
doesn't start with a lower case letter
[org.apache.accumulo.shell.commands.DeleteAuthsCommandTest] At
DeleteAuthsCommandTest.java:[lines 103-127]
[INFO] The method name
org.apache.accumulo.shell.commands.DeleteAuthsCommandTest.DeleteExistingAuth()
doesn't start with a lower case letter
[org.apache.accumulo.shell.commands.DeleteAuthsCommandTest] At
DeleteAuthsCommandTest.java:[lines 47-71]
[INFO] The method name
org.apache.accumulo.shell.commands.DeleteAuthsCommandTest.DeleteNonExistingAuth()
doesn't start with a lower case letter
[org.apache.accumulo.shell.commands.DeleteAuthsCommandTest] At
DeleteAuthsCommandTest.java:[lines 75-99]
{noformat}
You're welcome to send a new patch, otherwise, I can just fix the errors.
> Atomic add and remove of authorizations
> ---
>
> Key: ACCUMULO-1680
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1680
> Project: Accumulo
> Issue Type: New Feature
> Components: client, master, shell
>Affects Versions: 1.6.2
>Reporter: Chad Hardin
>Assignee: Eric Robertson
>Priority: Minor
> Labels: newbie, summit2015
> Fix For: 1.8.0
>
> Attachments: ACCUMULO-1680.patch
>
>
> Currently, adding and removing an auth presents a race condition because of
> the two separate calls required to get, modify, then set the authorizations
> for a user.
> Instead, it should be possible to add or remove one or more auths without
> there being a race condition.
> I also propose adding two new commands to the shell to expose this
> functionality.
> It appears to be that this is not a difficult feature to add, by making use
> of ZooReaderWriter.mutate() in the FATE packages. I think the bulk of the
> work will be in changing the various interfaces (shell and programmatically)
> to expose this functionality.
> I would like to do this work and I'm a accumulo newbie, so any guidance would
> be appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
