Accumulo-Integration-Tests - Build # 545 - Aborted! -- master
Accumulo-Integration-Tests - Build # 545 - Aborted: Check console output at https://secure.penguinsinabox.com/jenkins/job/Accumulo-Integration-Tests/545/ to view the results.
[jira] [Updated] (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:all-tabpanel ] marco polo updated ACCUMULO-3509: - Fix Version/s: 1.7.1 1.6.5 > 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.6.5, 1.7.1, 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-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=15081049#comment-15081049 ] marco polo commented on ACCUMULO-3509: -- Yes, shall I decline PR and target 1.6.5 so it can be merged up appropriately? > 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.6.5, 1.7.1, 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] [Resolved] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Newton resolved ACCUMULO-4063.
---
Resolution: Won't Fix
Any active checking for the lock would be expensive.
Any passive checking for a lock is the same as noticing the lock has failed and
exiting.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
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=15081142#comment-15081142 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user phrocker commented on the pull request: https://github.com/apache/accumulo/pull/60#issuecomment-168673706 I'm going to target 1.6.5 so it can be merged up. > 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.6.5, 1.7.1, 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-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=15081143#comment-15081143 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user phrocker closed the pull request at: https://github.com/apache/accumulo/pull/60 > 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.6.5, 1.7.1, 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-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081193#comment-15081193
]
Josh Elser commented on ACCUMULO-4063:
--
What about the calls that do check that the lock is held? It seems like
this is inconsistent.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081197#comment-15081197
]
Eric Newton commented on ACCUMULO-4063:
---
Are they checking on the master lock, or their own?
Some RPC calls might be worth the expense of an active check (load tablet), and
others less so (scan tablet).
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081246#comment-15081246
]
Josh Elser commented on ACCUMULO-4063:
--
bq. Are they checking on the master lock, or their own?
I thought they were checking their own, but I realized after my last comment I
should probably actually look at the code and figure out which calls do what.
Let me do that and get back.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081248#comment-15081248
]
Josh Elser commented on ACCUMULO-4063:
--
bq. Some RPC calls might be worth the expense of an active check
bq. Any passive checking for a lock is the same as noticing the lock has failed
and exiting.
I guess it's also worth mentioning that I did intend a passive check. The case
that I ran into when I filed this was a tabletserver starting before it ever
acquired it lock for the first time. I think this is an edge-case from what you
originally described. Maybe we can block the server starting until the lock is
acquired too which would be a bit more simple.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPC
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081250#comment-15081250
]
Eric Newton commented on ACCUMULO-4063:
---
We put the server's address in the lock. The address is often determined by
starting the server and having the OS pick the port. So, we kinda need the
server running to create the lock.
Alternatively, we can get the lock and put the address in later, but then we
need to change all the code that reads the address from the lock to handle the
starting case of an empty lock.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081253#comment-15081253
]
Josh Elser commented on ACCUMULO-4063:
--
Aha! Tricky. I will look at some code. There has to be a cleaner way to handle
the clean-start case than this. Any really big (I potentially find) will
obviously only hit 1.8.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081303#comment-15081303
]
Keith Turner commented on ACCUMULO-4063:
one other possible option :
* open server socket
* advertise port and create lock
* start thrift server service passing it the socket
unrelated, it may be cleaner if all request to a tserver to do something
included the expected tserver instance id in this case when a tserver gets
messages for a previous tserver instance it can drop them
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ACCUMULO-4063) TServer should verify its lock is held before answering any RPC
[
https://issues.apache.org/jira/browse/ACCUMULO-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081307#comment-15081307
]
Josh Elser commented on ACCUMULO-4063:
--
re: one other possible option, something along those lines is what I was
thinking of too, Keith.
> TServer should verify its lock is held before answering any RPC
> ---
>
> Key: ACCUMULO-4063
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4063
> Project: Accumulo
> Issue Type: Bug
> Components: rpc, tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
> Fix For: 1.7.2, 1.8.0
>
>
> Noticing the following:
> {noformat}
> 2015-11-19 22:42:47,130 [thrift.ProcessFunction] ERROR: Internal error
> processing flush
> org.apache.thrift.TException: Lock not acquired
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:51)
> at com.sun.proxy.$Proxy21.flush(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2671)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$flush.getResult(TabletClientService.java:2657)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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)
> 2015-11-19 22:42:47,402 [tserver.TabletServer$ThriftClientHandler] ERROR:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> java.lang.ClassCastException:
> org.apache.accumulo.tserver.session.MultiScanSession cannot be cast to
> org.apache.accumulo.tserver.session.ScanSession
> at
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeScan(TabletServer.java:574)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
> at
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:47)
> at com.sun.proxy.$Proxy21.closeScan(Unknown Source)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2309)
> at
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeScan.getResult(TabletClientService.java:2295)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
> at
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
> at
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
> 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}
> a {{flush}} rpc came in and was denied, but then a {{closeScan}} came in and
> threw an unrelated error (ignore the classcast for now).
> Are there _any_ RPCs that a tabletserver should answer before it holds its
> lock?
--
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=15081319#comment-15081319 ] ASF GitHub Bot commented on ACCUMULO-3509: -- GitHub user phrocker opened a pull request: https://github.com/apache/accumulo/pull/62 ACCUMULO-3509: Make cleanup stateful to minimize blocking By enabling state ( true/false) within the cleanup method, the change will avoid blocking on a scan session being swept. if the session cleanup blocks because a ScanSession is still being read, we may block until the ScanBatch returns for that ScanSession. The change uses a simple semaphore ( purely because I like the word ) to attempt acquisition. If that fails, we return false from the cleanup and reintroduce that Session back into the queue to clean up. You can merge this pull request into a Git repository by running: $ git pull https://github.com/phrocker/accumulo-1 1.6 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/accumulo/pull/62.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #62 commit 7918bd121e772738833a595ea3e83e5c76c6474c Author: phrocker Date: 2016-01-04T15:59:28Z ACCUMULO-3509: Make cleanup stateful to minimize blocking By enabling state ( true/false) within the cleanup method, the change will avoid blocking on a scan session being swept. if the session cleanup blocks because a ScanSession is still being read, we may block until the ScanBatch returns for that ScanSession. The change uses a simple semaphore ( purely because I like the word ) to attempt acquisition. If that fails, we return false from the cleanup and reintroduce that Session back into the queue to clean up. > 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.6.5, 1.7.1, 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-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=15081330#comment-15081330
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user keith-turner commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/60#discussion_r48749879
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Scanner.java ---
@@ -38,100 +40,126 @@
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+ protected Semaphore scannerSemaphore;
Scanner(Tablet tablet, Range range, ScanOptions options) {
this.tablet = tablet;
this.range = range;
this.options = options;
+scannerSemaphore = new Semaphore(1, true);
}
- public synchronized ScanBatch read() throws IOException,
TabletClosedException {
-
-if (sawException)
- throw new IllegalStateException("Tried to use scanner after
exception occurred.");
+ public ScanBatch read() throws IOException, TabletClosedException {
if (scanClosed)
--- End diff --
Below is from the semaphore javadoc. Reading that is sounds like there is
no guarantee of seeing a change to `scanClosed` until after `acquire()`.
```
Memory consistency effects: Actions in a thread prior to calling a
"release" method such as release() happen-before actions following a successful
"acquire" method such as acquire() in another thread.
```
> 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.6.5, 1.7.1, 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-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=15081362#comment-15081362
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user keith-turner commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/60#discussion_r48752641
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Scanner.java ---
@@ -38,100 +40,126 @@
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+ protected Semaphore scannerSemaphore;
Scanner(Tablet tablet, Range range, ScanOptions options) {
this.tablet = tablet;
this.range = range;
this.options = options;
+scannerSemaphore = new Semaphore(1, true);
--- End diff --
This semaphore replaces a synchronized block with a fair semaphore. AFAICT
from searching around on the web, synchronized blocks are not fair. Do we
need fairness here? The javadocs say its more expensive. If its not needed,
not sure should set it.
I was trying to determine the difference between the semaphore and a lock
for this case. It seems like the only difference is re-entrance, which it does
not seem is needed in this case.
> 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.6.5, 1.7.1, 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-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=15081371#comment-15081371
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/60#discussion_r48753072
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Scanner.java ---
@@ -38,100 +40,126 @@
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+ protected Semaphore scannerSemaphore;
Scanner(Tablet tablet, Range range, ScanOptions options) {
this.tablet = tablet;
this.range = range;
this.options = options;
+scannerSemaphore = new Semaphore(1, true);
--- End diff --
My only reason for enforcing fairness was that we likely only have a single
thread doing reads ( otherwise we'd have different sessions ); however, we will
have another thread doing a close. I wanted to enforce order in the event that
the read should occur first. In rethinking this I'm not terribly certain this a
problem.
As we discussed I only used a semaphore based on the aforementioned
assumption of a single thread doing reads within the scanner. I'm not tied to
the idea.
> 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.6.5, 1.7.1, 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-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=15081384#comment-15081384
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user phrocker commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/60#discussion_r48753512
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Scanner.java ---
@@ -38,100 +40,126 @@
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+ protected Semaphore scannerSemaphore;
Scanner(Tablet tablet, Range range, ScanOptions options) {
this.tablet = tablet;
this.range = range;
this.options = options;
+scannerSemaphore = new Semaphore(1, true);
}
- public synchronized ScanBatch read() throws IOException,
TabletClosedException {
-
-if (sawException)
- throw new IllegalStateException("Tried to use scanner after
exception occurred.");
+ public ScanBatch read() throws IOException, TabletClosedException {
if (scanClosed)
--- End diff --
I made a typo when writing the patch from my other machine. I made the
boolean volatile there but in talking with you I will move the scanClosed below
the acquisition to avoid the issue entirely and ensure cache coherency.
> 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.6.5, 1.7.1, 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-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=15081392#comment-15081392
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user keith-turner commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/60#discussion_r48753936
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Scanner.java ---
@@ -38,100 +40,126 @@
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+ protected Semaphore scannerSemaphore;
Scanner(Tablet tablet, Range range, ScanOptions options) {
this.tablet = tablet;
this.range = range;
this.options = options;
+scannerSemaphore = new Semaphore(1, true);
--- End diff --
The expense of fairness may not be a problem. I suspect the expense of
fairness is an issue for semaphores that are frequently accessed by many
threads, which is not the case here.
> 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.6.5, 1.7.1, 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] [Created] (ACCUMULO-4097) ContinuousVerify has required parameters that have reasonable defaults
Eric Newton created ACCUMULO-4097: - Summary: ContinuousVerify has required parameters that have reasonable defaults Key: ACCUMULO-4097 URL: https://issues.apache.org/jira/browse/ACCUMULO-4097 Project: Accumulo Issue Type: Bug Components: test Reporter: Eric Newton Assignee: Eric Newton Priority: Trivial Fix For: 1.8.0 "--output" "--maxMappers" and "--reducers" should not be required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ACCUMULO-4097) ContinuousVerify has required parameters that have reasonable defaults
[ https://issues.apache.org/jira/browse/ACCUMULO-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Newton resolved ACCUMULO-4097. --- Resolution: Fixed > ContinuousVerify has required parameters that have reasonable defaults > -- > > Key: ACCUMULO-4097 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4097 > Project: Accumulo > Issue Type: Bug > Components: test >Reporter: Eric Newton >Assignee: Eric Newton >Priority: Trivial > Fix For: 1.8.0 > > Time Spent: 10m > Remaining Estimate: 0h > > "--output" "--maxMappers" and "--reducers" should not be required. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-624) iterators may open lots of compressors
[ https://issues.apache.org/jira/browse/ACCUMULO-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081615#comment-15081615 ] marco polo commented on ACCUMULO-624: - [~ecn] I vaguely remembered a ticket by [~mdrob], and came across ACCUMULO-1534. Do you experience the same thing with snappy? > iterators may open lots of compressors > -- > > Key: ACCUMULO-624 > URL: https://issues.apache.org/jira/browse/ACCUMULO-624 > Project: Accumulo > Issue Type: Bug > Components: tserver >Reporter: Eric Newton > > A large iterator tree may create many instances of Compressors. These > instances are pulled from a pool that never decreases in size. So, if 50 > simultaneous queries are run over dozens of files, each with a complex > iterator stack, there will be thousands of compressors created. Each of > these holds a large buffer. This can cause the server to run out of memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-624) iterators may open lots of compressors
[ https://issues.apache.org/jira/browse/ACCUMULO-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081618#comment-15081618 ] marco polo commented on ACCUMULO-624: - If you don't have that test handy I can run a quick test. > iterators may open lots of compressors > -- > > Key: ACCUMULO-624 > URL: https://issues.apache.org/jira/browse/ACCUMULO-624 > Project: Accumulo > Issue Type: Bug > Components: tserver >Reporter: Eric Newton > > A large iterator tree may create many instances of Compressors. These > instances are pulled from a pool that never decreases in size. So, if 50 > simultaneous queries are run over dozens of files, each with a complex > iterator stack, there will be thousands of compressors created. Each of > these holds a large buffer. This can cause the server to run out of memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3734) Possible bug in VisibilityConstraint
[
https://issues.apache.org/jira/browse/ACCUMULO-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081647#comment-15081647
]
ASF GitHub Bot commented on ACCUMULO-3734:
--
Github user keith-turner closed the pull request at:
https://github.com/apache/accumulo/pull/59
> Possible bug in VisibilityConstraint
>
>
> Key: ACCUMULO-3734
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3734
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Keith Turner
> Fix For: 1.6.5, 1.7.1, 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> ACCUMULO-1681 modified which constructor from {{VisibilityEvaluator}} that
> {{VisibilityConstraint}} uses. After the modification {{escape()}} is no
> longer called (the old constructor called escape, and the new one does not).
> Not sure if this is a problem.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ACCUMULO-3734) Possible bug in VisibilityConstraint
[
https://issues.apache.org/jira/browse/ACCUMULO-3734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Turner resolved ACCUMULO-3734.
Resolution: Fixed
> Possible bug in VisibilityConstraint
>
>
> Key: ACCUMULO-3734
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3734
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Keith Turner
> Fix For: 1.6.5, 1.7.1, 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> ACCUMULO-1681 modified which constructor from {{VisibilityEvaluator}} that
> {{VisibilityConstraint}} uses. After the modification {{escape()}} is no
> longer called (the old constructor called escape, and the new one does not).
> Not sure if this is a problem.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ACCUMULO-4096) clean up user facing 1.5 remnants
[ https://issues.apache.org/jira/browse/ACCUMULO-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Billie Rinaldi reassigned ACCUMULO-4096: Assignee: Billie Rinaldi > clean up user facing 1.5 remnants > - > > Key: ACCUMULO-4096 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4096 > Project: Accumulo > Issue Type: Task > Components: website >Reporter: Sean Busbey >Assignee: Billie Rinaldi > > since 1.5 is EOM, we should make it less prominent in user facing areas. > * remove 1.5 from downloads > * remove from docs menu (move to 'docs for older versions' and leave old docs > to preserve external links) > * remove from release notes menu > * archive 1.5.4 release > * remove from dist.apache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-624) iterators may open lots of compressors
[ https://issues.apache.org/jira/browse/ACCUMULO-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081659#comment-15081659 ] Josh Elser commented on ACCUMULO-624: - I thought it was related to the pooling code, not the codec, but I could be completely wrong (as is often the case). If you have the cycles to write a test, feel free to include it as a utility in the accumulo-test maven module. This would be a nice tool to have in our pocket for the future! > iterators may open lots of compressors > -- > > Key: ACCUMULO-624 > URL: https://issues.apache.org/jira/browse/ACCUMULO-624 > Project: Accumulo > Issue Type: Bug > Components: tserver >Reporter: Eric Newton > > A large iterator tree may create many instances of Compressors. These > instances are pulled from a pool that never decreases in size. So, if 50 > simultaneous queries are run over dozens of files, each with a complex > iterator stack, there will be thousands of compressors created. Each of > these holds a large buffer. This can cause the server to run out of memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Accumulo-1.6 - Build # 936 - Still Failing
The Apache Jenkins build system has built Accumulo-1.6 (build #936) Status: Still Failing Check console output at https://builds.apache.org/job/Accumulo-1.6/936/ to view the results.
[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=15081671#comment-15081671
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48772476
--- Diff: core/src/main/java/org/apache/accumulo/core/conf/Property.java ---
@@ -226,6 +226,7 @@
TSERV_MEM_MGMT("tserver.memory.manager",
"org.apache.accumulo.server.tabletserver.LargestFirstMemoryManager",
PropertyType.CLASSNAME,
"An implementation of MemoryManger that accumulo will use."),
TSERV_SESSION_MAXIDLE("tserver.session.idle.max", "1m",
PropertyType.TIMEDURATION, "maximum idle time for a session"),
+ TSERV_UPDATE_SESSION_MAXIDLE("tserver.session.update.idle.max", "1m",
PropertyType.TIMEDURATION, "maximum idle time for an update session"),
--- End diff --
Could you make the new property description a complete sentence, please?
> 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.6.5, 1.7.1, 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-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=15081675#comment-15081675
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48773083
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/Tablet.java ---
@@ -1761,33 +1763,41 @@ Scanner createScanner(Range range, int num,
Set columns, Authorizations
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+private Semaphore scannerSemaphore;
Scanner(Range range, ScanOptions options) {
this.range = range;
this.options = options;
+ scannerSemaphore = new Semaphore(1, true);
}
-synchronized ScanBatch read() throws IOException,
TabletClosedException {
+ScanBatch read() throws IOException, TabletClosedException {
- if (sawException)
-throw new IllegalStateException("Tried to use scanner after
exception occurred.");
-
- if (scanClosed)
-throw new IllegalStateException("Tried to use scanner after it was
closed.");
+ ScanDataSource dataSource = null;
Batch results = null;
- ScanDataSource dataSource;
+ try {
- if (options.isolated) {
-if (isolatedDataSource == null)
- isolatedDataSource = new ScanDataSource(options);
-dataSource = isolatedDataSource;
- } else {
-dataSource = new ScanDataSource(options);
- }
+try {
+ scannerSemaphore.acquire();
+} catch (InterruptedException e) {
+ sawException = true;
+}
- try {
+if (sawException)
+ throw new IllegalStateException("Tried to use scanner after
exception occurred.");
--- End diff --
Isn't this exception message a little misleading now if we catch the
InterruptedException above? Would it be better to throw an ISE from the catch
block above with a better message? Or, do we not care what exception we saw?
> 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.6.5, 1.7.1, 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-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=15081706#comment-15081706 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user joshelser commented on a diff in the pull request: https://github.com/apache/accumulo/pull/62#discussion_r48775109 --- Diff: server/tserver/src/main/java/org/apache/accumulo/tserver/Tablet.java --- @@ -1761,33 +1763,41 @@ Scanner createScanner(Range range, int num, Set columns, Authorizations private ScanDataSource isolatedDataSource; private boolean sawException = false; private boolean scanClosed = false; +private Semaphore scannerSemaphore; --- End diff -- A javadoc comment describing why a semaphore is used would be nice when looking at this code in the future. > 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.6.5, 1.7.1, 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] [Resolved] (ACCUMULO-4096) clean up user facing 1.5 remnants
[ https://issues.apache.org/jira/browse/ACCUMULO-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Billie Rinaldi resolved ACCUMULO-4096. -- Resolution: Fixed > clean up user facing 1.5 remnants > - > > Key: ACCUMULO-4096 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4096 > Project: Accumulo > Issue Type: Task > Components: website >Reporter: Sean Busbey >Assignee: Billie Rinaldi > Time Spent: 10m > Remaining Estimate: 0h > > since 1.5 is EOM, we should make it less prominent in user facing areas. > * remove 1.5 from downloads > * remove from docs menu (move to 'docs for older versions' and leave old docs > to preserve external links) > * remove from release notes menu > * archive 1.5.4 release > * remove from dist.apache -- 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=15081786#comment-15081786
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48779554
--- Diff:
test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java
---
@@ -0,0 +1,181 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.accumulo.test.functional;
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+import java.util.Map.Entry;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Future;
+
+import org.apache.accumulo.core.client.BatchWriter;
+import org.apache.accumulo.core.client.BatchWriterConfig;
+import org.apache.accumulo.core.client.Connector;
+import org.apache.accumulo.core.client.IteratorSetting;
+import org.apache.accumulo.core.client.Scanner;
+import org.apache.accumulo.core.client.admin.ActiveScan;
+import org.apache.accumulo.core.client.admin.InstanceOperations;
+import org.apache.accumulo.core.conf.AccumuloConfiguration;
+import org.apache.accumulo.core.conf.Property;
+import org.apache.accumulo.core.data.Key;
+import org.apache.accumulo.core.data.Mutation;
+import org.apache.accumulo.core.data.Range;
+import org.apache.accumulo.core.data.Value;
+import org.apache.accumulo.core.security.Authorizations;
+import org.apache.accumulo.harness.AccumuloClusterIT;
+import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.io.Text;
+import org.junit.Before;
+import org.junit.Test;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Verify that we have resolved blocking issue by ensuring that we have
not lost scan sessions which we know to currently be running
+ */
+public class SessionBlockVerifyIT extends AccumuloClusterIT {
+ private static final Logger log =
LoggerFactory.getLogger(SessionBlockVerifyIT.class);
+
+ @Override
+ public void configureMiniCluster(MiniAccumuloConfigImpl cfg,
Configuration hadoopCoreSite) {
+Map siteConfig = cfg.getSiteConfig();
+cfg.setNumTservers(1);
+siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11");
+cfg.setSiteConfig(siteConfig);
+ }
+
+ @Override
+ protected int defaultTimeoutSeconds() {
+return 60;
+ }
+
+ private String sessionIdle = null;
+
+ @Before
+ public void reduceSessionIdle() throws Exception {
+
+InstanceOperations ops = getConnector().instanceOperations();
+sessionIdle =
ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey());
+ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+log.info("Waiting for existing session idle time to expire");
+Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle));
+log.info("Finished waiting");
+ }
+
+ ExecutorService service = Executors.newFixedThreadPool(10);
--- End diff --
Create this inside the test case? Or in a `@BeforeClass`? Something that we
can make sure it is cleaned up after the test completes.
> Scanner lock cause Tablet lock, hence preventing idle scans from being swept,
> hence blocking SimpleTimer thread
>
>
> Key:
[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=15081788#comment-15081788
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48779729
--- Diff:
test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java
---
@@ -0,0 +1,181 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.accumulo.test.functional;
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+import java.util.Map.Entry;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Future;
+
+import org.apache.accumulo.core.client.BatchWriter;
+import org.apache.accumulo.core.client.BatchWriterConfig;
+import org.apache.accumulo.core.client.Connector;
+import org.apache.accumulo.core.client.IteratorSetting;
+import org.apache.accumulo.core.client.Scanner;
+import org.apache.accumulo.core.client.admin.ActiveScan;
+import org.apache.accumulo.core.client.admin.InstanceOperations;
+import org.apache.accumulo.core.conf.AccumuloConfiguration;
+import org.apache.accumulo.core.conf.Property;
+import org.apache.accumulo.core.data.Key;
+import org.apache.accumulo.core.data.Mutation;
+import org.apache.accumulo.core.data.Range;
+import org.apache.accumulo.core.data.Value;
+import org.apache.accumulo.core.security.Authorizations;
+import org.apache.accumulo.harness.AccumuloClusterIT;
+import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.io.Text;
+import org.junit.Before;
+import org.junit.Test;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Verify that we have resolved blocking issue by ensuring that we have
not lost scan sessions which we know to currently be running
+ */
+public class SessionBlockVerifyIT extends AccumuloClusterIT {
+ private static final Logger log =
LoggerFactory.getLogger(SessionBlockVerifyIT.class);
+
+ @Override
+ public void configureMiniCluster(MiniAccumuloConfigImpl cfg,
Configuration hadoopCoreSite) {
+Map siteConfig = cfg.getSiteConfig();
+cfg.setNumTservers(1);
+siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11");
+cfg.setSiteConfig(siteConfig);
+ }
+
+ @Override
+ protected int defaultTimeoutSeconds() {
+return 60;
+ }
+
+ private String sessionIdle = null;
+
+ @Before
+ public void reduceSessionIdle() throws Exception {
+
+InstanceOperations ops = getConnector().instanceOperations();
+sessionIdle =
ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey());
+ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+log.info("Waiting for existing session idle time to expire");
+Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle));
+log.info("Finished waiting");
+ }
+
+ ExecutorService service = Executors.newFixedThreadPool(10);
+
+ @Test
+ public void run() throws Exception {
+Connector c = getConnector();
+String tableName = getUniqueNames(1)[0];
+c.tableOperations().create(tableName);
+
+BatchWriter bw = c.createBatchWriter(tableName, new
BatchWriterConfig());
+
+for (int i = 0; i < 1000; i++) {
+ Mutation m = new Mutation(new Text(String.format("%08d", i)));
+
[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=15081792#comment-15081792
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48779936
--- Diff:
test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java
---
@@ -0,0 +1,181 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.accumulo.test.functional;
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+import java.util.Map.Entry;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Future;
+
+import org.apache.accumulo.core.client.BatchWriter;
+import org.apache.accumulo.core.client.BatchWriterConfig;
+import org.apache.accumulo.core.client.Connector;
+import org.apache.accumulo.core.client.IteratorSetting;
+import org.apache.accumulo.core.client.Scanner;
+import org.apache.accumulo.core.client.admin.ActiveScan;
+import org.apache.accumulo.core.client.admin.InstanceOperations;
+import org.apache.accumulo.core.conf.AccumuloConfiguration;
+import org.apache.accumulo.core.conf.Property;
+import org.apache.accumulo.core.data.Key;
+import org.apache.accumulo.core.data.Mutation;
+import org.apache.accumulo.core.data.Range;
+import org.apache.accumulo.core.data.Value;
+import org.apache.accumulo.core.security.Authorizations;
+import org.apache.accumulo.harness.AccumuloClusterIT;
+import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.io.Text;
+import org.junit.Before;
+import org.junit.Test;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Verify that we have resolved blocking issue by ensuring that we have
not lost scan sessions which we know to currently be running
+ */
+public class SessionBlockVerifyIT extends AccumuloClusterIT {
+ private static final Logger log =
LoggerFactory.getLogger(SessionBlockVerifyIT.class);
+
+ @Override
+ public void configureMiniCluster(MiniAccumuloConfigImpl cfg,
Configuration hadoopCoreSite) {
+Map siteConfig = cfg.getSiteConfig();
+cfg.setNumTservers(1);
+siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11");
+cfg.setSiteConfig(siteConfig);
+ }
+
+ @Override
+ protected int defaultTimeoutSeconds() {
+return 60;
+ }
+
+ private String sessionIdle = null;
+
+ @Before
+ public void reduceSessionIdle() throws Exception {
+
+InstanceOperations ops = getConnector().instanceOperations();
+sessionIdle =
ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey());
+ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+log.info("Waiting for existing session idle time to expire");
+Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle));
+log.info("Finished waiting");
+ }
+
+ ExecutorService service = Executors.newFixedThreadPool(10);
+
+ @Test
+ public void run() throws Exception {
+Connector c = getConnector();
+String tableName = getUniqueNames(1)[0];
+c.tableOperations().create(tableName);
+
+BatchWriter bw = c.createBatchWriter(tableName, new
BatchWriterConfig());
+
+for (int i = 0; i < 1000; i++) {
+ Mutation m = new Mutation(new Text(String.format("%08d", i)));
+
[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=15081794#comment-15081794
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48780215
--- Diff:
test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java
---
@@ -0,0 +1,181 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.accumulo.test.functional;
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+import java.util.Map.Entry;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Future;
+
+import org.apache.accumulo.core.client.BatchWriter;
+import org.apache.accumulo.core.client.BatchWriterConfig;
+import org.apache.accumulo.core.client.Connector;
+import org.apache.accumulo.core.client.IteratorSetting;
+import org.apache.accumulo.core.client.Scanner;
+import org.apache.accumulo.core.client.admin.ActiveScan;
+import org.apache.accumulo.core.client.admin.InstanceOperations;
+import org.apache.accumulo.core.conf.AccumuloConfiguration;
+import org.apache.accumulo.core.conf.Property;
+import org.apache.accumulo.core.data.Key;
+import org.apache.accumulo.core.data.Mutation;
+import org.apache.accumulo.core.data.Range;
+import org.apache.accumulo.core.data.Value;
+import org.apache.accumulo.core.security.Authorizations;
+import org.apache.accumulo.harness.AccumuloClusterIT;
+import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.io.Text;
+import org.junit.Before;
+import org.junit.Test;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Verify that we have resolved blocking issue by ensuring that we have
not lost scan sessions which we know to currently be running
+ */
+public class SessionBlockVerifyIT extends AccumuloClusterIT {
+ private static final Logger log =
LoggerFactory.getLogger(SessionBlockVerifyIT.class);
+
+ @Override
+ public void configureMiniCluster(MiniAccumuloConfigImpl cfg,
Configuration hadoopCoreSite) {
+Map siteConfig = cfg.getSiteConfig();
+cfg.setNumTservers(1);
+siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11");
+cfg.setSiteConfig(siteConfig);
+ }
+
+ @Override
+ protected int defaultTimeoutSeconds() {
+return 60;
+ }
+
+ private String sessionIdle = null;
+
+ @Before
+ public void reduceSessionIdle() throws Exception {
+
+InstanceOperations ops = getConnector().instanceOperations();
+sessionIdle =
ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey());
+ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+log.info("Waiting for existing session idle time to expire");
+Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle));
+log.info("Finished waiting");
+ }
+
+ ExecutorService service = Executors.newFixedThreadPool(10);
+
+ @Test
+ public void run() throws Exception {
+Connector c = getConnector();
+String tableName = getUniqueNames(1)[0];
+c.tableOperations().create(tableName);
+
+BatchWriter bw = c.createBatchWriter(tableName, new
BatchWriterConfig());
+
+for (int i = 0; i < 1000; i++) {
+ Mutation m = new Mutation(new Text(String.format("%08d", i)));
+
[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=15081796#comment-15081796
]
ASF GitHub Bot commented on ACCUMULO-3509:
--
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48780266
--- Diff:
test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java
---
@@ -0,0 +1,181 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.accumulo.test.functional;
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertTrue;
+
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+import java.util.Map.Entry;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.Future;
+
+import org.apache.accumulo.core.client.BatchWriter;
+import org.apache.accumulo.core.client.BatchWriterConfig;
+import org.apache.accumulo.core.client.Connector;
+import org.apache.accumulo.core.client.IteratorSetting;
+import org.apache.accumulo.core.client.Scanner;
+import org.apache.accumulo.core.client.admin.ActiveScan;
+import org.apache.accumulo.core.client.admin.InstanceOperations;
+import org.apache.accumulo.core.conf.AccumuloConfiguration;
+import org.apache.accumulo.core.conf.Property;
+import org.apache.accumulo.core.data.Key;
+import org.apache.accumulo.core.data.Mutation;
+import org.apache.accumulo.core.data.Range;
+import org.apache.accumulo.core.data.Value;
+import org.apache.accumulo.core.security.Authorizations;
+import org.apache.accumulo.harness.AccumuloClusterIT;
+import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl;
+import org.apache.hadoop.conf.Configuration;
+import org.apache.hadoop.io.Text;
+import org.junit.Before;
+import org.junit.Test;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+/**
+ * Verify that we have resolved blocking issue by ensuring that we have
not lost scan sessions which we know to currently be running
+ */
+public class SessionBlockVerifyIT extends AccumuloClusterIT {
+ private static final Logger log =
LoggerFactory.getLogger(SessionBlockVerifyIT.class);
+
+ @Override
+ public void configureMiniCluster(MiniAccumuloConfigImpl cfg,
Configuration hadoopCoreSite) {
+Map siteConfig = cfg.getSiteConfig();
+cfg.setNumTservers(1);
+siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11");
+cfg.setSiteConfig(siteConfig);
+ }
+
+ @Override
+ protected int defaultTimeoutSeconds() {
+return 60;
+ }
+
+ private String sessionIdle = null;
+
+ @Before
+ public void reduceSessionIdle() throws Exception {
+
+InstanceOperations ops = getConnector().instanceOperations();
+sessionIdle =
ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey());
+ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s");
+log.info("Waiting for existing session idle time to expire");
+Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle));
+log.info("Finished waiting");
+ }
+
+ ExecutorService service = Executors.newFixedThreadPool(10);
+
+ @Test
+ public void run() throws Exception {
+Connector c = getConnector();
+String tableName = getUniqueNames(1)[0];
+c.tableOperations().create(tableName);
+
+BatchWriter bw = c.createBatchWriter(tableName, new
BatchWriterConfig());
+
+for (int i = 0; i < 1000; i++) {
+ Mutation m = new Mutation(new Text(String.format("%08d", i)));
+
[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=15081798#comment-15081798 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user joshelser commented on the pull request: https://github.com/apache/accumulo/pull/62#issuecomment-168807086 Looks pretty good, @phrocker. I left you some nit-picky suggestions which would improve the changes a bit and hopefully make sure your included integration test runs on any hardware (yay, included integration test!!). > 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.6.5, 1.7.1, 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-4096) clean up user facing 1.5 remnants
[ https://issues.apache.org/jira/browse/ACCUMULO-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081821#comment-15081821 ] Sean Busbey commented on ACCUMULO-4096: --- Thanks Billie! > clean up user facing 1.5 remnants > - > > Key: ACCUMULO-4096 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4096 > Project: Accumulo > Issue Type: Task > Components: website >Reporter: Sean Busbey >Assignee: Billie Rinaldi > Time Spent: 10m > Remaining Estimate: 0h > > since 1.5 is EOM, we should make it less prominent in user facing areas. > * remove 1.5 from downloads > * remove from docs menu (move to 'docs for older versions' and leave old docs > to preserve external links) > * remove from release notes menu > * archive 1.5.4 release > * remove from dist.apache -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ACCUMULO-4098) ConditionalWriterIT is failing
Keith Turner created ACCUMULO-4098:
--
Summary: ConditionalWriterIT is failing
Key: ACCUMULO-4098
URL: https://issues.apache.org/jira/browse/ACCUMULO-4098
Project: Accumulo
Issue Type: Bug
Reporter: Keith Turner
Priority: Blocker
Fix For: 1.8.0
I noticed that the ConditionalWriterIT was failing in master. Using the
following command with {{git bisect}} I tracked it down to commit {{3af75fc}}
for ACCUMULO-4077 as the change which broke the IT. Have not looked into why
its failing yet.
{noformat}
mvn clean verify -Dit.test=ConditionalWriterIT -Dfindbugs.skip
-Dcheckstyle.skip -Dtest=foo -DfailIfNoTests=false
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ACCUMULO-4098) ConditionalWriterIT is failing
[
https://issues.apache.org/jira/browse/ACCUMULO-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Turner reassigned ACCUMULO-4098:
--
Assignee: Keith Turner
> ConditionalWriterIT is failing
> --
>
> Key: ACCUMULO-4098
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4098
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Keith Turner
>Priority: Blocker
> Fix For: 1.8.0
>
>
> I noticed that the ConditionalWriterIT was failing in master. Using the
> following command with {{git bisect}} I tracked it down to commit {{3af75fc}}
> for ACCUMULO-4077 as the change which broke the IT. Have not looked into why
> its failing yet.
> {noformat}
> mvn clean verify -Dit.test=ConditionalWriterIT -Dfindbugs.skip
> -Dcheckstyle.skip -Dtest=foo -DfailIfNoTests=false
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Accumulo-Integration-Tests - Build # 546 - Aborted! -- 1.6
Accumulo-Integration-Tests - Build # 546 - Aborted: Check console output at https://secure.penguinsinabox.com/jenkins/job/Accumulo-Integration-Tests/546/ to view the results.
Accumulo-Integration-Tests - Build # 547 - Aborted! -- 1.7
Accumulo-Integration-Tests - Build # 547 - Aborted: Check console output at https://secure.penguinsinabox.com/jenkins/job/Accumulo-Integration-Tests/547/ to view the results.
[jira] [Commented] (ACCUMULO-2493) BinaryFormatter needs to be refactored
[ https://issues.apache.org/jira/browse/ACCUMULO-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082377#comment-15082377 ] ASF GitHub Bot commented on ACCUMULO-2493: -- Github user joshelser commented on the pull request: https://github.com/apache/accumulo/pull/61#issuecomment-168897649 This looks really good! Lots of new tests, new docs, and BinaryFormatter is cleaned up nicely by the FormatterConfig. Anyone else have any input before I run some tests and merge it in? > BinaryFormatter needs to be refactored > -- > > Key: ACCUMULO-2493 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2493 > Project: Accumulo > Issue Type: Bug > Components: client >Reporter: Mike Drob >Assignee: Matt Dailey > Labels: newbie > Fix For: 1.7.1, 1.8.0 > > > BinaryFormatter is currently used in a couple places in the shell, but the > code is hard to read and understand. There is a static getlength, which is > actually a setter, and all the instance calls end up going through > unnecessary static methods. > This combination makes it hard to reuse BinaryFormatter objects, or even use > multiple, since the static state is likely to conflict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-2493) BinaryFormatter needs to be refactored
[
https://issues.apache.org/jira/browse/ACCUMULO-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082445#comment-15082445
]
Josh Elser commented on ACCUMULO-2493:
--
Ran this through Yetus for funsies:
Full console: https://paste.apache.org/d29E
{noformat}
+1 overall
_
/ ___| _ _ ___ ___ ___ ___ ___| |
\___ \| | | |/ __/ __/ _ \/ __/ __| |
___) | |_| | (_| (_| __/\__ \__ \_|
|/ \__,_|\___\___\___||___/___(_)
{noformat}
| Vote | Subsystem | Runtime | Comment
| +1 | @author | 0m 00s| The patch does not contain any @author
| ||| tags.
| +1 |test4tests | 0m 00s| The patch appears to include 11 new or
| ||| modified test files.
| +1 |mvninstall | 1m 58s| 1.7 passed
| +1 | compile | 1m 24s| 1.7 passed
| +1 |checkstyle | 1m 01s| 1.7 passed
| +1 |mvneclipse | 1m 06s| 1.7 passed
| +1 | findbugs | 3m 55s| 1.7 passed
| +1 | javadoc | 1m 17s| 1.7 passed
| +1 |mvninstall | 1m 28s| the patch passed
| +1 | compile | 1m 22s| the patch passed
| +1 | javac | 1m 22s| the patch passed
| +1 |checkstyle | 1m 03s| the patch passed
| +1 |mvneclipse | 1m 06s| the patch passed
| +1 |whitespace | 0m 00s| Patch has no whitespace issues.
| +1 | findbugs | 4m 09s| the patch passed
| +1 | javadoc | 1m 27s| the patch passed
| +1 |asflicense | 0m 36s| Patch does not generate ASF License
| ||| warnings.
| || 22m 39s |
|| Subsystem || Report/Notes ||
| GITHUB PR | https://github.com/apache/accumulo/pull/61 |
| JIRA Issue | ACCUMULO-2493 |
| Optional Tests | asflicense javac javadoc unit findbugs checkstyle
compile |
| uname | Darwin hw10447.local 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1
21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64 |
| Build tool | maven |
| Personality |
/usr/local/lib/yetus-0.1.0/lib/precommit/personality/Accumulo.sh |
| git revision | 1.7 / ff08336 |
| findbugs | v3.0.1 |
| modules | C: core server/base server/tracer shell U: . |
| Powered by | Apache Yetus 0.1.0 http://yetus.apache.org |
I do think I forgot to add the "run-tests" flag, however...
> BinaryFormatter needs to be refactored
> --
>
> Key: ACCUMULO-2493
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2493
> Project: Accumulo
> Issue Type: Bug
> Components: client
>Reporter: Mike Drob
>Assignee: Matt Dailey
> Labels: newbie
> Fix For: 1.7.1, 1.8.0
>
>
> BinaryFormatter is currently used in a couple places in the shell, but the
> code is hard to read and understand. There is a static getlength, which is
> actually a setter, and all the instance calls end up going through
> unnecessary static methods.
> This combination makes it hard to reuse BinaryFormatter objects, or even use
> multiple, since the static state is likely to conflict.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
