[jira] [Commented] (ACCUMULO-2008) Block cache reserves section for in-memory blocks

[Billie Rinaldi (Jira)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17057440#comment-17057440
 ] 

Billie Rinaldi commented on ACCUMULO-2008:
--

Looks like it still defaults to leaving 25% of the cache unused (for anyone 
interested in fixing this in their cluster's configuration). It's okay with me 
to close this since it is configurable now. Thanks [~ctubbsii]!

> Block cache reserves section for in-memory blocks
> -
>
> Key: ACCUMULO-2008
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2008
> Project: Accumulo
>  Issue Type: Bug
>  Components: tserver
>Affects Versions: 1.4.4, 1.5.0, 1.6.0
>Reporter: Billie Rinaldi
>Priority: Major
>
> The block cache reserves a quarter of its size for in-memory blocks, but 
> Accumulo doesn't have any in-memory blocks.  This makes the cache size 
> parameters misleading, because the cache will effectively end up using 75% of 
> its specified size.  This could be fixed by changing the default percentages 
> in LruBlockCache, or by using the constructor takes the percentages as 
> parameters.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (ACCUMULO-4564) Replace with on the website

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-4564.
--
Resolution: Fixed

> Replace  with  on the website
> -
>
> Key: ACCUMULO-4564
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4564
> Project: Accumulo
>  Issue Type: Bug
>  Components: website
>Reporter: Billie Rinaldi
>Assignee: Billie Rinaldi
>
> Now that Accumulo is a registered trademark, we should update the TM 
> references on the website.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-4564) Replace with on the website

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-4564:


 Summary: Replace  with  on the website
 Key: ACCUMULO-4564
 URL: https://issues.apache.org/jira/browse/ACCUMULO-4564
 Project: Accumulo
  Issue Type: Bug
  Components: website
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi


Now that Accumulo is a registered trademark, we should update the TM references 
on the website.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-4529) ChangeSecret doesn't correct tracers

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-4529.
--
Resolution: Duplicate

> ChangeSecret doesn't correct tracers
> 
>
> Key: ACCUMULO-4529
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4529
> Project: Accumulo
>  Issue Type: Bug
>  Components: trace
>Affects Versions: 1.7.2
>Reporter: John Vines
>
> ChangeSecret will rewrite everything under /accumulo/instancesecret for the 
> new instance secret, including correcting the ACL for the users. 
> Unfortunately because we changed where tracers were registered (but didn't 
> change how they were ACLed) so ChangeSecret no longer hits the default tracer 
> path znode (nor does it attempt to locate what the appropriate path is). This 
> results in the new instance being unable to spin up tracers since they cannot 
> register themselves in ZK because their path is not writable using the new 
> instance secret.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4415) Tracer requires instance.secret

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542495#comment-15542495
 ] 

Billie Rinaldi commented on ACCUMULO-4415:
--

Why? Different Accumulo instances should be configured with different ZK nodes 
for tracers (trace.zookeeper.path).

> Tracer requires instance.secret
> ---
>
> Key: ACCUMULO-4415
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4415
> Project: Accumulo
>  Issue Type: Bug
>  Components: trace
>Reporter: Christopher Tubbs
>Priority: Critical
> Fix For: 2.0.0
>
>
> Tracer incorrectly uses instance.secret for its /tracers area in ZooKeeper.
> The tracer does not use the Accumulo system credentials, and instead uses a 
> specific tracer username and password. It should also not use the 
> instance.secret (which is for the system credentials).
> A side effect of this bug is that ChangeSecret does not update the /tracers 
> ACLs in ZooKeeper, preventing the tracer from working entirely after the 
> instance.secret is changed.
> The following error will be seen in the monitor after the ChangeSecret tool 
> is run.
> {code}
> Thread 'tracer' died.
>   org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = 
> NoAuth for /tracers/trace-
>   at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:113)
>   at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>   at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
>   at 
> org.apache.accumulo.fate.zookeeper.ZooUtil.putEphemeralSequential(ZooUtil.java:464)
>   at 
> org.apache.accumulo.fate.zookeeper.ZooReaderWriter.putEphemeralSequential(ZooReaderWriter.java:99)
>   at 
> org.apache.accumulo.tracer.TraceServer.registerInZooKeeper(TraceServer.java:318)
>   at 
> org.apache.accumulo.tracer.TraceServer.(TraceServer.java:255)
>   at 
> org.apache.accumulo.tracer.TraceServer.main(TraceServer.java:360)
>   at 
> org.apache.accumulo.tracer.TracerExecutable.execute(TracerExecutable.java:33)
>   at org.apache.accumulo.start.Main$1.run(Main.java:120)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> This affects at least the current 1.8 branch (1.8.0-SNAPSHOT), but I haven't 
> checked earlier versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4415) Tracer requires instance.secret

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15427399#comment-15427399
 ] 

Billie Rinaldi commented on ACCUMULO-4415:
--

Tracer registration used to be under the instance ID zk node, and it was moved 
so that HDFS could be configured to send traces to Accumulo's span receiver.

> Tracer requires instance.secret
> ---
>
> Key: ACCUMULO-4415
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4415
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Christopher Tubbs
> Fix For: 1.8.1
>
>
> Tracer incorrectly uses instance.secret for its /tracers area in ZooKeeper.
> The tracer does not use the Accumulo system credentials, and instead uses a 
> specific tracer username and password. It should also not use the 
> instance.secret (which is for the system credentials).
> A side effect of this bug is that ChangeSecret does not update the /tracers 
> ACLs in ZooKeeper, preventing the tracer from working entirely after the 
> instance.secret is changed.
> The following error will be seen in the monitor after the ChangeSecret tool 
> is run.
> {code}
> Thread 'tracer' died.
>   org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = 
> NoAuth for /tracers/trace-
>   at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:113)
>   at 
> org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>   at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:783)
>   at 
> org.apache.accumulo.fate.zookeeper.ZooUtil.putEphemeralSequential(ZooUtil.java:464)
>   at 
> org.apache.accumulo.fate.zookeeper.ZooReaderWriter.putEphemeralSequential(ZooReaderWriter.java:99)
>   at 
> org.apache.accumulo.tracer.TraceServer.registerInZooKeeper(TraceServer.java:318)
>   at 
> org.apache.accumulo.tracer.TraceServer.(TraceServer.java:255)
>   at 
> org.apache.accumulo.tracer.TraceServer.main(TraceServer.java:360)
>   at 
> org.apache.accumulo.tracer.TracerExecutable.execute(TracerExecutable.java:33)
>   at org.apache.accumulo.start.Main$1.run(Main.java:120)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> This affects at least the current 1.8 branch (1.8.0-SNAPSHOT), but I haven't 
> checked earlier versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4362) TabletStateChangeIteratorIT failure on cloning metadata table

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373478#comment-15373478
 ] 

Billie Rinaldi commented on ACCUMULO-4362:
--

That's already on the allow list ... so maybe it's something else?

> TabletStateChangeIteratorIT failure on cloning metadata table
> -
>
> Key: ACCUMULO-4362
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4362
> Project: Accumulo
>  Issue Type: Bug
>  Components: test
>Reporter: Josh Elser
>Priority: Critical
> Fix For: 1.8.0, 1.9.0
>
>
> In the Master log:
> {noformat}
> 2016-07-09 16:22:15,858 [master.MasterClientServiceHandler] ERROR:  table 
> deleted during clone?  srcTableId = !0 tableId=4
> java.lang.RuntimeException:  table deleted during clone?  srcTableId = !0 
> tableId=4
>   at 
> org.apache.accumulo.server.util.MetadataTableUtil.checkClone(MetadataTableUtil.java:753)
>   at 
> org.apache.accumulo.server.util.MetadataTableUtil.cloneTable(MetadataTableUtil.java:842)
>   at 
> org.apache.accumulo.master.tableOps.CloneMetadata.call(CloneMetadata.java:45)
>   at 
> org.apache.accumulo.master.tableOps.CloneMetadata.call(CloneMetadata.java:24)
>   at org.apache.accumulo.master.tableOps.TraceRepo.call(TraceRepo.java:57)
>   at org.apache.accumulo.fate.Fate$TransactionRunner.run(Fate.java:74)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
>   at java.lang.Thread.run(Thread.java:745)
> 2016-07-09 16:22:15,859 [thrift.ProcessFunction] ERROR: Internal error 
> processing waitForFateOperation
> org.apache.thrift.TException:  table deleted during clone?  srcTableId = !0 
> tableId=4
>   at 
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:81)
>   at com.sun.proxy.$Proxy10.waitForFateOperation(Unknown Source)
>   at 
> org.apache.accumulo.core.master.thrift.FateService$Processor$waitForFateOperation.getResult(FateService.java:481)
>   at 
> org.apache.accumulo.core.master.thrift.FateService$Processor$waitForFateOperation.getResult(FateService.java:465)
>   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:518)
>   at 
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.invoke(CustomNonBlockingServer.java:106)
>   at org.apache.thrift.server.Invocation.run(Invocation.java:18)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The test case:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.544 sec <<< 
> FAILURE! - in org.apache.accumulo.test.functional.TabletStateChangeIteratorIT
> test(org.apache.accumulo.test.functional.TabletStateChangeIteratorIT)  Time 
> elapsed: 7.402 sec  <<< ERROR!
> org.apache.accumulo.core.client.AccumuloException: Internal error processing 
> waitForFateOperation
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.cloneMetadataTable(TabletStateChangeIteratorIT.java:201)
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.test(TabletStateChangeIteratorIT.java:103)
> Caused by: org.apache.thrift.TApplicationException: Internal error processing 
> waitForFateOperation
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.cloneMetadataTable(TabletStateChangeIteratorIT.java:201)
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.test(TabletStateChangeIteratorIT.java:103)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4362) TabletStateChangeIteratorIT failure on cloning metadata table

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15373450#comment-15373450
 ] 

Billie Rinaldi commented on ACCUMULO-4362:
--

I may be the only active moderator for our lists. Things sent from unapproved 
addresses to notifications@ might be rejected automatically without going 
through moderation, though. At least, I haven't gotten any moderation 
notifications for jenkins.revelc.net. If we figure out the sending address, I 
can add it to the allow list -- you don't have to ask INFRA for that.

> TabletStateChangeIteratorIT failure on cloning metadata table
> -
>
> Key: ACCUMULO-4362
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4362
> Project: Accumulo
>  Issue Type: Bug
>  Components: test
>Reporter: Josh Elser
>Priority: Critical
> Fix For: 1.8.0, 1.9.0
>
>
> In the Master log:
> {noformat}
> 2016-07-09 16:22:15,858 [master.MasterClientServiceHandler] ERROR:  table 
> deleted during clone?  srcTableId = !0 tableId=4
> java.lang.RuntimeException:  table deleted during clone?  srcTableId = !0 
> tableId=4
>   at 
> org.apache.accumulo.server.util.MetadataTableUtil.checkClone(MetadataTableUtil.java:753)
>   at 
> org.apache.accumulo.server.util.MetadataTableUtil.cloneTable(MetadataTableUtil.java:842)
>   at 
> org.apache.accumulo.master.tableOps.CloneMetadata.call(CloneMetadata.java:45)
>   at 
> org.apache.accumulo.master.tableOps.CloneMetadata.call(CloneMetadata.java:24)
>   at org.apache.accumulo.master.tableOps.TraceRepo.call(TraceRepo.java:57)
>   at org.apache.accumulo.fate.Fate$TransactionRunner.run(Fate.java:74)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
>   at java.lang.Thread.run(Thread.java:745)
> 2016-07-09 16:22:15,859 [thrift.ProcessFunction] ERROR: Internal error 
> processing waitForFateOperation
> org.apache.thrift.TException:  table deleted during clone?  srcTableId = !0 
> tableId=4
>   at 
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:81)
>   at com.sun.proxy.$Proxy10.waitForFateOperation(Unknown Source)
>   at 
> org.apache.accumulo.core.master.thrift.FateService$Processor$waitForFateOperation.getResult(FateService.java:481)
>   at 
> org.apache.accumulo.core.master.thrift.FateService$Processor$waitForFateOperation.getResult(FateService.java:465)
>   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:518)
>   at 
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$CustomFrameBuffer.invoke(CustomNonBlockingServer.java:106)
>   at org.apache.thrift.server.Invocation.run(Invocation.java:18)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at 
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The test case:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.544 sec <<< 
> FAILURE! - in org.apache.accumulo.test.functional.TabletStateChangeIteratorIT
> test(org.apache.accumulo.test.functional.TabletStateChangeIteratorIT)  Time 
> elapsed: 7.402 sec  <<< ERROR!
> org.apache.accumulo.core.client.AccumuloException: Internal error processing 
> waitForFateOperation
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.cloneMetadataTable(TabletStateChangeIteratorIT.java:201)
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.test(TabletStateChangeIteratorIT.java:103)
> Caused by: org.apache.thrift.TApplicationException: Internal error processing 
> waitForFateOperation
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.cloneMetadataTable(TabletStateChangeIteratorIT.java:201)
>   at 
> org.apache.accumulo.test.functional.TabletStateChangeIteratorIT.test(TabletStateChangeIteratorIT.java:103)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4364) "Already loaded span receivers" log message in shell

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371194#comment-15371194
 ] 

Billie Rinaldi commented on ACCUMULO-4364:
--

Oh, it looks like the Shell tracing isn't being disabled property.  
DistributedTrace.enable is called when we do shell.config in ShellServerIT, but 
DistributedTrace.disable is only performed in Shell.execute(String[] args), 
which is not being called in the IT.

> "Already loaded span receivers" log message in shell
> 
>
> Key: ACCUMULO-4364
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4364
> Project: Accumulo
>  Issue Type: Bug
>  Components: shell
>Reporter: Josh Elser
> Fix For: 2.0.0
>
>
> {noformat}
> 2016-07-10 22:43:53,846 [trace.DistributedTrace] INFO : Already loaded span 
> receivers, enable tracing does not need to be called again
> {noformat}
> Noticed this one in the test output for ShellServerIT on master (not sure if 
> it's also happening in other branches).
> Seems to imply that we might be making unnecessary HTrace calls. WDYT, 
> [~billie.rinaldi] -- have you run into this before?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4364) "Already loaded span receivers" log message in shell

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15371158#comment-15371158
 ] 

Billie Rinaldi commented on ACCUMULO-4364:
--

I'm not sure why this would be happening in the master.  That gets logged if 
DistributedTrace.enable happens more than once.  I could see this occurring on 
the client side, but in the master it gets called in the main method.  It's an 
INFO-level message, so it shouldn't be causing a problem, but couldn't hurt to 
look into why it's doing that.

> "Already loaded span receivers" log message in shell
> 
>
> Key: ACCUMULO-4364
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4364
> Project: Accumulo
>  Issue Type: Bug
>  Components: shell
>Reporter: Josh Elser
> Fix For: 2.0.0
>
>
> {noformat}
> 2016-07-10 22:43:53,846 [trace.DistributedTrace] INFO : Already loaded span 
> receivers, enable tracing does not need to be called again
> {noformat}
> Noticed this one in the test output for ShellServerIT on master (not sure if 
> it's also happening in other branches).
> Seems to imply that we might be making unnecessary HTrace calls. WDYT, 
> [~billie.rinaldi] -- have you run into this before?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4331) Make port configuration and allocation consistent across services

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15318876#comment-15318876
 ] 

Billie Rinaldi commented on ACCUMULO-4331:
--

Not really; it's easier to set it to 0 when you don't care what the port is, 
and that's consistent with other projects (e.g. HBase). What's the argument for 
not allowing 0?

> Make port configuration and allocation consistent across services
> -
>
> Key: ACCUMULO-4331
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4331
> Project: Accumulo
>  Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Dave Marion
> Fix For: 1.8.0
>
>
> There was some discussion in ACCUMULO-4328 about ports, so I decided to track 
> down how the client ports are configured and allocated. Issues raised in the 
> discussion were:
>  1. The port search feature was not well understood
>  2. Ephemeral port allocation makes it hard to lock servers down (e.g. 
> iptables)
> Looking through the code I found the following properties allocate a port 
> number based on conf.getPort(). This returns the port number based on the 
> property and supports either a single value or zero. Then, in the server 
> component (monitor, tracer, gc, etc) this value is used when creating a 
> ServerSocket. If the port is already in use, the process will fail.
> {noformat}
> monitor.port.log4j
> trace.port.client
> gc.port.client
> monitor.port.client
> {noformat}
> The following properties use TServerUtils.startServer which uses the value in 
> the property to start the TServer. If the value is zero, then it picks a 
> random port between 1024 and 65535. If tserver.port.search is enabled, then 
> it will try a thousand times to bind to a random port.
> {noformat}
> tserver.port.client
> master.port.client
> master.replication.coordinator.port
> replication.receipt.service.port
> {noformat}
> I'm proposing that we deprecate the tserver.port.search property and the 
> value zero in the property value for the properties above. Instead, I think 
> we should allow the user to specify a single value or a range (M-N). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4331) Make port configuration and allocation consistent across services

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15318827#comment-15318827
 ] 

Billie Rinaldi commented on ACCUMULO-4331:
--

I'd prefer not deprecating the 0 option.  Accumulo on Slider uses that.

> Make port configuration and allocation consistent across services
> -
>
> Key: ACCUMULO-4331
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4331
> Project: Accumulo
>  Issue Type: Bug
>Affects Versions: 1.8.0
>Reporter: Dave Marion
> Fix For: 1.8.0
>
>
> There was some discussion in ACCUMULO-4328 about ports, so I decided to track 
> down how the client ports are configured and allocated. Issues raised in the 
> discussion were:
>  1. The port search feature was not well understood
>  2. Ephemeral port allocation makes it hard to lock servers down (e.g. 
> iptables)
> Looking through the code I found the following properties allocate a port 
> number based on conf.getPort(). This returns the port number based on the 
> property and supports either a single value or zero. Then, in the server 
> component (monitor, tracer, gc, etc) this value is used when creating a 
> ServerSocket. If the port is already in use, the process will fail.
> {noformat}
> monitor.port.log4j
> trace.port.client
> gc.port.client
> monitor.port.client
> {noformat}
> The following properties use TServerUtils.startServer which uses the value in 
> the property to start the TServer. If the value is zero, then it picks a 
> random port between 1024 and 65535. If tserver.port.search is enabled, then 
> it will try a thousand times to bind to a random port.
> {noformat}
> tserver.port.client
> master.port.client
> master.replication.coordinator.port
> replication.receipt.service.port
> {noformat}
> I'm proposing that we deprecate the tserver.port.search property and the 
> value zero in the property value for the properties above. Instead, I think 
> we should allow the user to specify a single value or a range (M-N). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Deleted] (ACCUMULO-4283) Call,1-855-800-8493 #Netflix support phone number, Netflix technical support numHerry 1855 800 8493 Netflix t.e.c.h s.u.p.p.o.r.t p.h.o.n.e number

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi deleted ACCUMULO-4283:
-


> Call,1-855-800-8493 #Netflix support phone number, Netflix technical support 
> numHerry 1855 800 8493 Netflix t.e.c.h s.u.p.p.o.r.t p.h.o.n.e number 
> ---
>
> Key: ACCUMULO-4283
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4283
> Project: Accumulo
>  Issue Type: Bug
>Reporter: makmskmee
>
> # Netflix  Toll Free, @(1.855.800.8493)@-: Netflix  Tech Support Phone Number 
> vides online solution for all USA/CANADA clients. For any help of query call 
> 1 855 to get all Netflix  account solution. @@Call, +1.855.800.8493 for all 
> type help by Netflix  tech support phone number, Netflix  Tech Support Phone 
> Number, Netflix  Help Desk Phone Number, Netflix  tech support number, 
> Netflix  technical support phone number,@@@ Netflix  phone number, Netflix  
> technical support number, Netflix  support phone number, Netflix  technical 
> support, Netflix  Customer Service Phone Number, Netflix  Customer Service 
> Number, Netflix  Customer Support Phone Number,
> Netflix  Customer Support Number, Netflix  Customer Service Helpline 
> Number, Netflix  Customer Care Number, Netflix  support team phone number, 
> @ Netflix  help number- Netflix  Helpline Number; Netflix  help phone 
> number- Netflix  Helpline Number, Netflix  Tech Support Toll free Number, 
> Netflix  Support Telephone Number, Netflix  Tech Support Telephone number, 
> Netflix  Tech Support contact number, Netflix  support contact number, 
> Netflix  technical support contact number. Call, Netflix  tech support phone 
> number, Netflix  Tech Support Phone Number, Netflix  Help Desk Phone Number, 
> Netflix  tech support number, Netflix  technical support phone number, 
> Netflix  phone number, Netflix  technical support number, Netflix  support 
> phone number. It is very popular toll free number which vide by Netflix  
> technical support, Netflix  Customer Service Phone Number, Netflix  Customer 
> Service Number, Netflix  Customer Support Phone Number, Netflix  Customer 
> Support Number, Netflix  Customer Service Helpline Number, Netflix  Customer 
> Care Number, Netflix  support team phone number. Call, Netflix  tech support 
> phone number, Netflix  Tech Support Phone Number, Netflix  Help Desk Phone 
> Number, Netflix  tech support number, Netflix  technical support phone 
> number, Netflix  phone number, Netflix  technical support number, Netflix  
> support phone number, Netflix  technical support, Netflix  Customer Service 
> Phone Number, Netflix  Customer Service Number, Netflix  Customer Support 
> Phone Number, Netflix  Customer Support Number, Netflix  Customer Service 
> Helpline Number, Netflix  Customer Care Number, Netflix  support team phone 
> number,
> https://www.youtube.com/watch?v=mEyQOnyRLMY
> Netflix  Toll Free, @(1-855-800-8493)Netflix  Tech Support Phone Number vides 
> online solution for all USA/CANADA clients. For any help of query call 1 855 
> 800 8493 to get all  Netflix  account solution.
> @@Call, 1-855-800-8493 for all type help by Netflix  tech support phone 
> number, Netflix  Tech Support Phone Number, Netflix  Help Desk Phone Number, 
> Netflix  tech support number, Netflix  technical support phone number,@@@ 
> Netflix  phone number, Netflix  technical support number, Netflix  support 
> phone number, Netflix  technical support, Netflix  Customer Service Phone 
> Number, Netflix  Customer Service Number, Netflix  Customer Support Phone 
> Number, Netflix  Customer Support Number, Netflix  Customer Service 
> Helpline Number, Netflix  Customer Care Number, Netflix  support team phone 
> number, #
> Netflix  help number- Netflix  Helpline Number;  Netflix  help phone number- 
> Netflix  Helpline Number,  Netflix  Tech Support Toll free Number,  Netflix  
> Support Telephone Number,  Netflix  Tech Support Telephone number,  Netflix  
> Tech Support contact number,  Netflix  support contact number,  Netflix  
> technical support contact number. Call US 1 855 800 8493  Netflix  tech 
> support phone number 1 855 800 8493  Netflix  customer service phone number 
> 855 8008493  Netflix  support technical support phone number 1 855 800 8493  
> Netflix  customer support phone number~..Call,..1 (855) 800.8493:  
> Netflix  service phone number..Call,..1 (855) 800.8493:  Netflix  support 
> phone number..Call,..1 (855) 800.8493:  Netflix  support phone 
> number..Call,..1 (855) 800.8493:  Netflix  support phone number..Call,..1 
> (855) 800.8493:  Netflix  support phone number..Call,..1 (855) 
> 800.8493:  Netflix  support phone number..Call,..1 (855) 

[jira] [Deleted] (ACCUMULO-4284) Call,1-855-800-8493 #Netflix support phone number, Netflix technical support 1855 800 8493 Netflix t.e.c.h s.u.p.p.o.r.t p.h.o.n.e number

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi deleted ACCUMULO-4284:
-


> Call,1-855-800-8493 #Netflix support phone number, Netflix technical support 
> 1855 800 8493 Netflix t.e.c.h s.u.p.p.o.r.t p.h.o.n.e number
> -
>
> Key: ACCUMULO-4284
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4284
> Project: Accumulo
>  Issue Type: Bug
>Reporter: makmskmee
>
> Call,1-855-800-8493 #Netflix support phone number, Netflix technical support 
> 1855 800 8493 Netflix t.e.c.h s.u.p.p.o.r.t p.h.o.n.e number
> # Netflix  Toll Free, @(1.855.800.8493)@-: Netflix  Tech Support Phone Number 
> vides online solution for all USA/CANADA clients. For any help of query call 
> 1 855 to get all Netflix  account solution. @@Call, +1.855.800.8493 for all 
> type help by Netflix  tech support phone number, Netflix  Tech Support Phone 
> Number, Netflix  Help Desk Phone Number, Netflix  tech support number, 
> Netflix  technical support phone number,@@@ Netflix  phone number, Netflix  
> technical support number, Netflix  support phone number, Netflix  technical 
> support, Netflix  Customer Service Phone Number, Netflix  Customer Service 
> Number, Netflix  Customer Support Phone Number,
> Netflix  Customer Support Number, Netflix  Customer Service Helpline 
> Number, Netflix  Customer Care Number, Netflix  support team phone number, 
> @ Netflix  help number- Netflix  Helpline Number; Netflix  help phone 
> number- Netflix  Helpline Number, Netflix  Tech Support Toll free Number, 
> Netflix  Support Telephone Number, Netflix  Tech Support Telephone number, 
> Netflix  Tech Support contact number, Netflix  support contact number, 
> Netflix  technical support contact number. Call, Netflix  tech support phone 
> number, Netflix  Tech Support Phone Number, Netflix  Help Desk Phone Number, 
> Netflix  tech support number, Netflix  technical support phone number, 
> Netflix  phone number, Netflix  technical support number, Netflix  support 
> phone number. It is very popular toll free number which vide by Netflix  
> technical support, Netflix  Customer Service Phone Number, Netflix  Customer 
> Service Number, Netflix  Customer Support Phone Number, Netflix  Customer 
> Support Number, Netflix  Customer Service Helpline Number, Netflix  Customer 
> Care Number, Netflix  support team phone number. Call, Netflix  tech support 
> phone number, Netflix  Tech Support Phone Number, Netflix  Help Desk Phone 
> Number, Netflix  tech support number, Netflix  technical support phone 
> number, Netflix  phone number, Netflix  technical support number, Netflix  
> support phone number, Netflix  technical support, Netflix  Customer Service 
> Phone Number, Netflix  Customer Service Number, Netflix  Customer Support 
> Phone Number, Netflix  Customer Support Number, Netflix  Customer Service 
> Helpline Number, Netflix  Customer Care Number, Netflix  support team phone 
> number,
> https://www.youtube.com/watch?v=mEyQOnyRLMY
> Netflix  Toll Free, @(1-855-800-8493)Netflix  Tech Support Phone Number vides 
> online solution for all USA/CANADA clients. For any help of query call 1 855 
> 800 8493 to get all  Netflix  account solution.
> @@Call, 1-855-800-8493 for all type help by Netflix  tech support phone 
> number, Netflix  Tech Support Phone Number, Netflix  Help Desk Phone Number, 
> Netflix  tech support number, Netflix  technical support phone number,@@@ 
> Netflix  phone number, Netflix  technical support number, Netflix  support 
> phone number, Netflix  technical support, Netflix  Customer Service Phone 
> Number, Netflix  Customer Service Number, Netflix  Customer Support Phone 
> Number, Netflix  Customer Support Number, Netflix  Customer Service 
> Helpline Number, Netflix  Customer Care Number, Netflix  support team phone 
> number, #
> Netflix  help number- Netflix  Helpline Number;  Netflix  help phone number- 
> Netflix  Helpline Number,  Netflix  Tech Support Toll free Number,  Netflix  
> Support Telephone Number,  Netflix  Tech Support Telephone number,  Netflix  
> Tech Support contact number,  Netflix  support contact number,  Netflix  
> technical support contact number. Call US 1 855 800 8493  Netflix  tech 
> support phone number 1 855 800 8493  Netflix  customer service phone number 
> 855 8008493  Netflix  support technical support phone number 1 855 800 8493  
> Netflix  customer support phone number~..Call,..1 (855) 800.8493:  
> Netflix  service phone number..Call,..1 (855) 800.8493:  Netflix  support 
> phone number..Call,..1 (855) 800.8493:  Netflix  support phone 
> number..Call,..1 (855) 800.8493:  Netflix  support phone number..Call,..1 
> (855) 

[jira] [Deleted] (ACCUMULO-4242) Microsoft Outlook Mail +1800 - 929 - 1150 Outlook Mail Technical Support Phone Number

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi deleted ACCUMULO-4242:
-


> Microsoft Outlook Mail +1800 - 929 - 1150 Outlook Mail Technical Support 
> Phone Number
> -
>
> Key: ACCUMULO-4242
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4242
> Project: Accumulo
>  Issue Type: New Feature
> Environment: Microsoft Outlook Mail +1800 - 929 - 1150 Outlook Mail 
> Technical Support Phone Number
> Microsoft Outlook Mail +1800 - 929 - 1150 Outlook Mail Technical Support 
> Phone Number
>Reporter: susan lee
>Priority: Trivial
>  Labels: documentation
>
> outlook tech support phone number
> outlook technical support phone number
> outlook customer care number
> contact number for microsoft outlook
> microsoft outlook tech support phone number
> outlook technical support number
> outlook customer support phone number
> microsoft outlook customer support phone number
> microsoft outlook technical support number usa
> outlook email support phone number
> phone number for microsoft outlook technical support
> microsoft outlook support number
> microsoft outlook email support phone number
> microsoft outlook phone number
> outlook phone number
> microsoft outlook customer service phone number
> microsoft outlook support phone number us
> outlook express technical support phone number
> microsoft outlook help phone number
> outlook help phone number
> outlook customer service phone number
> outlook support number
> microsoft outlook contact number
> outlook tech support number
> microsoft outlook tech support number
> microsoft outlook help number
> outlook.com support phone number
> outlook email tech support phone number
> phone number for microsoft outlook support
> phone number for microsoft outlook
> outlook customer service number
> microsoft outlook support contact phone number
> microsoft outlook phone number support
> microsoft outlook customer service number
> phone number for outlook support
> outlook customer support number
> outlook contact number
> outlook helpline number
> microsoft outlook number
> outlook tech support number usa
> microsoft outlook contact phone number
> microsoft outlook customer support number
> phone number for outlook
> outlook.com phone number
> outlook support phone number canada
> microsoft outlook outlook customer service phone number
> outlook express support phone number
> outlook.com customer support phone number
> microsoft outlook email support number
> microsoft outlook email help phone number
> outlook help number
> microsoft outlook help desk phone number
> outlook.com support number
> phone number for outlook email
> outlook email phone number
> outlook.com help phone number
> outlook email support number
> microsoft outlook support number canada
> outlook support number usa
> outlook support telephone number
> outlook telephone number
> outlook customer service telephone number
> outlook telephone support
> outlook techincal support phone number
> outlook techincal support number
> outlook techical support facebook
> outlook technical help and support phone number
> outlook technical suppot telephone number
> outlook technical support support number usa
> usa
> outlook technical support number usa
> us
> microsoft outlook techinal support number
> outlook technical support email
> microsoft outlook email technical support number 
> outlook express technical support phone number
> outlook 2010 technical support phone number
> microsoft outlook email support phone number
> microsoft outlook email support number
> microsoft outlook email sign in support number
> microsoft outlook email signature support number
> outlook express technical support number
> microsoft outlook 2007 support number
> microsoft outlook 2010 technical support phone number
> microsoft outlook technical support phone number
> microsoft outlook tech support phone number
> microsoft outlook email technical support number
> Query resolved call:: 1.800.480.5092 
> outlook technical support telephone number
> microsoft outlook technical support number
> microsoft outllok 2010 technical support phone number
> microsoft outlook exprss technical support phone number
> microsoft outlook 365 technical support phone number
> microsoft outlook express tech support phone number
> microsoft outlook 2013 technical support number
> microsoft outlook customer support phone number
> microsoft outlook 2010 technical support 
> outlook support phone number
> outlook phone number us
> outlook tech support phone number
> outlook support number us
> contact number for outlook
> outlook customer service number us
> outlook email contact number
> outlook email help number
> contact number for outlook email

[jira] [Commented] (ACCUMULO-4192) Analyze Threading for Tracing correctness

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244438#comment-15244438
 ] 

Billie Rinaldi commented on ACCUMULO-4192:
--

Yeah, I kind of gathered that, I just wanted to provide some context as to why 
it was removed.  Adding Trace.wrap for individual Runnables or using 
TraceExecutorService to wrap a thread pool would be fine.  The problem that was 
fixed was that a Runnable that stays around for the entire life of the thread 
pool was being wrapped, instead of wrapping individual tasks executed by the 
pool.  I started a list of areas we might want to examine in the description of 
that ticket (things I thought might be affected by the change).

> Analyze Threading for Tracing correctness
> -
>
> Key: ACCUMULO-4192
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4192
> Project: Accumulo
>  Issue Type: Task
>  Components: trace
>Reporter: Josh Elser
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> When we switched from cloudtrace to htrace, we lost an implicit 
> {{TraceRunnable}} wrapper in NamingThreadFactory (which is used by 
> SimpleThreadPool). This results in the current Trace's span being lost across 
> threads.
> We should inspect uses of SimpleThreadPool (and maybe TraceRunnable in 1.6) 
> to make sure that we don't have any other hidden tracing problems before the 
> next 1.7 and 1.8 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4192) Analyze Threading for Tracing correctness

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244421#comment-15244421
 ] 

Billie Rinaldi commented on ACCUMULO-4192:
--

I think the removal of that TraceRunnable was fixing a bug: ACCUMULO-3507. It 
was sort of related to switching to htrace, in that switching to htrace 
revealed the bug.

> Analyze Threading for Tracing correctness
> -
>
> Key: ACCUMULO-4192
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4192
> Project: Accumulo
>  Issue Type: Task
>  Components: trace
>Reporter: Josh Elser
>Priority: Blocker
> Fix For: 1.7.2, 1.8.0
>
>
> When we switched from cloudtrace to htrace, we lost an implicit 
> {{TraceRunnable}} wrapper in NamingThreadFactory (which is used by 
> SimpleThreadPool). This results in the current Trace's span being lost across 
> threads.
> We should inspect uses of SimpleThreadPool (and maybe TraceRunnable in 1.6) 
> to make sure that we don't have any other hidden tracing problems before the 
> next 1.7 and 1.8 release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-4171:
-
Description: 
We are currently using HTrace 3.1.0-incubating. There were some API changes and 
improvements on the way to HTrace 4.x-incubating, and we should stay up to date 
with those changes.

Currently you can extend Accumulo tracing down into HDFS if you're using 
Accumulo 1.7 and Hadoop 2.7. This ticket is for continuing to make that work 
for versions of Hadoop > 2.7.

  was:We are currently using HTrace 3.1.0-incubating. There were some API 
changes and improvements on the way to HTrace 4.x-incubating, and we should 
stay up to date with those changes.


> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.
> Currently you can extend Accumulo tracing down into HDFS if you're using 
> Accumulo 1.7 and Hadoop 2.7. This ticket is for continuing to make that work 
> for versions of Hadoop > 2.7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230684#comment-15230684
 ] 

Billie Rinaldi commented on ACCUMULO-4171:
--

Currently you can extend Accumulo tracing down into HDFS if you're using 
Accumulo 1.7 and Hadoop 2.7.  This ticket is for continuing to make that work 
for versions of Hadoop > 2.7.

> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15216237#comment-15216237
 ] 

Billie Rinaldi commented on ACCUMULO-4171:
--

Ah, that kind of makes sense.  Do you recall why it seemed impossible to use?  
The only issue I encountered was that HDFS generates way too many spans, but we 
dealt with that in the Accumulo SpanReceiver by dropping the 0ms spans.

> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15215029#comment-15215029
 ] 

Billie Rinaldi commented on ACCUMULO-4171:
--

Unfortunately it seems as if that ship has already sailed -- Hadoop 2.6 and 
Hadoop 2.7 shipped with incompatible versions of htrace (the package name 
change upon move to Apache), and commits were made 6 months ago to Hadoop 2.8 
branch to change to a third incompatible version.  The htrace community seems 
to be moving in a direction of better compatibility across versions, at least.

> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214376#comment-15214376
 ] 

Billie Rinaldi commented on ACCUMULO-4171:
--

You're right, it will be helpful if the APIs we use haven't broken across 
htrace 4 versions; I was dreading a > 2 version shim.  Some time ago I started 
looking into shimming htrace 3.1.0 and 4.0.1 and it seemed like that might be 
possible.

> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214354#comment-15214354
 ] 

Billie Rinaldi commented on ACCUMULO-4171:
--

Yes, I think the main area of difficulty is that Accumulo implements its own 
SpanReceiver.

> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-4171) Update to htrace-core4

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15214287#comment-15214287
 ] 

Billie Rinaldi commented on ACCUMULO-4171:
--

No stability guarantees as of yet, and I understand that [4.0.1 and 4.1.0 are 
not 
compatible|http://mail-archives.apache.org/mod_mbox/htrace-dev/201602.mbox/%3CCADcMMgEkb7-JA3Ng3kbXvCtxDA5Ad9__SSxtO227B6aH6EGR6w%40mail.gmail.com%3E].
  My rough plan was to wait until there is a released version of Hadoop that 
uses htrace 4 and see if it's possible to make a shim that works with the 
current dependency and the new dependency (2.8 branch and later now have 
4.0.1-incubating; I don't know if anyone is planning to update that to 
4.1.0-incubating).

> Update to htrace-core4
> --
>
> Key: ACCUMULO-4171
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4171
> Project: Accumulo
>  Issue Type: Improvement
>  Components: trace
>Reporter: Mike Drob
> Fix For: 1.8.0
>
>
> We are currently using HTrace 3.1.0-incubating. There were some API changes 
> and improvements on the way to HTrace 4.x-incubating, and we should stay up 
> to date with those changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ACCUMULO-4096) clean up user facing 1.5 remnants

[Billie Rinaldi (JIRA)]

 [ 
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] [Resolved] (ACCUMULO-4096) clean up user facing 1.5 remnants

[Billie Rinaldi (JIRA)]

 [ 
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-3741) Reduce incompatibilities with htrace 3.2.0-incubating

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14745485#comment-14745485
 ] 

Billie Rinaldi commented on ACCUMULO-3741:
--

Looks like HDFS may skip htrace 3.2.0-incubating and go right to 
4.0.0-incubating (HDFS-9080), in which case we should use that version instead.

> Reduce incompatibilities with htrace 3.2.0-incubating
> -
>
> Key: ACCUMULO-3741
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3741
> Project: Accumulo
>  Issue Type: Bug
>Reporter: Billie Rinaldi
>Assignee: Billie Rinaldi
> Fix For: 1.8.0
>
> Attachments: ACCUMULO-3741.1.patch, ACCUMULO-3741.2.patch, 
> ACCUMULO-3741.3.patch
>
>
> HTrace 3.2.0-incubating is coming out soon and there are some significant 
> differences in its API.  Ideally we would like Accumulo to work with either 
> version.  Differences include:
> * no Trace.setProcessId method
> * process ID is handled differently now; it defaults to name/IP, while before 
> Accumulo tracked IP manually
> * SpanReceivers are expected to set process ID if it is not provided
> * return type of Span.getKVAnnotations changed from Map to 
> Map
> * Spans can now have multiple parents (although none do yet) and getParentId 
> has been replaced by getParents which returns a list of longs
> * multiple parents means there is no longer a fixed root span ID; root spans 
> just have an empty list of parents



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3991) fix source tarball LICENSE /NOTICE files

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14739891#comment-14739891
 ] 

Billie Rinaldi commented on ACCUMULO-3991:
--

Hey Sean, the files mentioned in ACCUMULO-3989 are based on old HBase versions 
of the same (thus the copyright notice in their headers).  See 
http://s.apache.org/JXi for reference; that was a while ago, but some of it is 
still relevant.

> fix source tarball LICENSE /NOTICE files
> 
>
> Key: ACCUMULO-3991
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3991
> Project: Accumulo
>  Issue Type: Sub-task
>  Components: build
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 1.5.4
>
> Attachments: ACCUMULO-3991.1.patch
>
>
> see parent issue for details



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3970) Generating multiple views of a value at scan time

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14709418#comment-14709418
 ] 

Billie Rinaldi commented on ACCUMULO-3970:
--

I guess the problem is that this represents a shift in control of data 
visibility from the data producer to, say, the table admin.  There's nothing to 
enforce that the value is transformed, so someone could set up an iterator that 
just outputs the key/value pair with a different visibility:
{noformat}
(pt_id, demographic, pt_dob, SHD_DOB) - 1925-08-22
{noformat}
Perhaps designing an iterator that only performed masking or truncation would 
address this issue.  We'd still want the data producer to be able to control 
the amount of transformation required, and possibly specify a list of 
visibilities that can view the masked values.

 Generating multiple views of a value at scan time
 -

 Key: ACCUMULO-3970
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3970
 Project: Accumulo
  Issue Type: New Feature
Reporter: Russ Weeks
Priority: Minor
 Fix For: 1.8.0


 It would be useful to have the ability to generate different representations 
 of a key-value pair at scan time, based on the scan authorizations.
 For example, consider [HIPPA safe harbour 
 de-identification|http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/De-identification/guidance.html#dates].
  One of the rules for de-identifying a patient's date of birth is that if a 
 patient is 89 years old or younger, you can disclose his exact year of birth. 
 If a patient is 90 years old or over, you pretend that he's 90 years old.
 You can imagine implementing this as a key/value mapping in accumulo like,
 {{(pt_id, demographic, pt_dob, PII_DOB) - 1925-08-22}}
 {{(pt_id, demographic, pt_dob, SHD_DOB) - 1925}}
 Where the value corresponding to visibility SHD_DOB is produced at scan-time, 
 depending on the patient's current age.
 Another example would be the ability to produce a salted hash of a unique 
 identifier like a social security number or medical record number, where the 
 salt (or the hash algorithm, or the work factor...) could be specified 
 dynamically without having to re-code all the values in the system.
 More broadly speaking, this feature would give organizations more flexibility 
 to change how they deidentify, transform or anonymize data to suit different 
 access levels.
 Of course, to do this you'd need to have a pluggable component that can 
 process key/value pairs before visibilities are evaluated. I can see why this 
 might give a lot of people the heeby-jeebies but I'd like to gather as much 
 feedback as possible. Looking forward to hearing your thoughts!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-925) Launch scripts should use a PIDfile

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14603638#comment-14603638
 ] 

Billie Rinaldi commented on ACCUMULO-925:
-

I have a feeling we need to add a command line parameter that will allow us to 
specify which conf dir to use.

 Launch scripts should use a PIDfile
 ---

 Key: ACCUMULO-925
 URL: https://issues.apache.org/jira/browse/ACCUMULO-925
 Project: Accumulo
  Issue Type: Improvement
  Components: scripts
Reporter: Christopher Tubbs
Assignee: Billie Rinaldi
 Fix For: 1.8.0

 Attachments: ACCUMULO-925.1.patch, ACCUMULO-925.2.patch


 Start scripts should create PIDfiles to store the PID of running processes in 
 a well known location (example: /var/run/accumulo/tserver.pid or 
 $ACCUMULO_HOME/tserver.pid), for the following benefits:
 # Identify running services on a machine without executing and parsing the 
 system process list, so stop scripts can kill them when they are unresponsive.
 # Prevent multiple instances of the same application from starting up (an 
 environment variable for the location of the PIDfile can be used to allow 
 multiple instances if it is desirable to do so).
 # Potentially provide an alternate mechanism for terminating a process by 
 deleting its PIDfile rather than its lock in Zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks for the reviews, everyone!

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0, 1.6.3

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.part2.patch, 
 ACCUMULO-3890.5.patch, ACCUMULO-3890.6.patch, ACCUMULO-3890.7.patch

  Time Spent: 1h
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582173#comment-14582173
 ] 

Billie Rinaldi commented on ACCUMULO-3890:
--

Well, I was trying to avoid synchronizing every read, since we were discussing 
that this could result in worse performance.  It seems like if the initial read 
doesn't find the object, it will load new providers, and then do a synchronized 
read or put, throwing away the new providers if it can read them.  Do you think 
that's not a good approach?

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.5.part2.patch

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.part2.patch, 
 ACCUMULO-3890.5.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14582250#comment-14582250
 ] 

Billie Rinaldi commented on ACCUMULO-3890:
--

Yes, the part2 patch is relative.  You're right, I missed that it always 
returns the previous value, even if null.  I'll fix that.

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.part2.patch, 
 ACCUMULO-3890.5.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.6.patch

Here's a consolidated patch.

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.part2.patch, 
 ACCUMULO-3890.5.patch, ACCUMULO-3890.6.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.7.patch

Good idea.

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.part2.patch, 
 ACCUMULO-3890.5.patch, ACCUMULO-3890.6.patch, ACCUMULO-3890.7.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.3.patch

Thanks for the tip, [~lmccay].  This looks a lot cleaner.

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch


 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.4.patch

Thanks for taking a look, [~busbey].

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch


 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.5.patch

I added the comment Sean requested, removed the synchronization from the 
method, and just synchronized around the put to the cachedProviders.

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.patch


 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Fix Version/s: 1.6.3

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch, 
 ACCUMULO-3890.3.patch, ACCUMULO-3890.4.patch, ACCUMULO-3890.5.patch

  Time Spent: 10m
  Remaining Estimate: 0h

 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.1.patch

Here's an approach I'm experimenting with.

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch


 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3890:
-
Attachment: ACCUMULO-3890.2.patch

 Use of CredentialProvider results in a lot of NN ops
 

 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1, 1.8.0

 Attachments: ACCUMULO-3890.1.patch, ACCUMULO-3890.2.patch


 Every time we access a sensitive property or iterate over a configuration 
 when there is a CredentialProvider configured, it results in NN operations 
 (as evidenced by FSNamesystem.audit logs).  I think that we could assume the 
 CredentialProvider is static, read its properties once and cache them in 
 memory to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3895) Accumulo init can fail halfway through

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578901#comment-14578901
 ] 

Billie Rinaldi commented on ACCUMULO-3895:
--

It catches the error and logs [init.Initialize] ERROR: FATAL Failed to 
initialize filesystem. Checking that we can create a fine is an interesting 
idea, though maybe not necessary if we are sure we'll always get an exception 
if there's a problem.

 Accumulo init can fail halfway through
 --

 Key: ACCUMULO-3895
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3895
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Priority: Critical

 I saw a situation where accumulo init exited with error code 255, the HDFS 
 directories were successfully created, and security was not initialized.  The 
 contents of accumulo-init.out were the following.  I realize no good can come 
 of running init when there are no DataNodes, but it would be nice if init 
 cleaned up after itself when it fails.
 {noformat}
 2015-06-08 23:19:17,930 [fs.VolumeManagerImpl] WARN : 
 dfs.datanode.synconclose set to false in hdfs-site.xml: data loss is possible 
 on hard system reset or power loss
 2015-06-08 23:19:17,932 [init.Initialize] INFO : Hadoop Filesystem is 
 hdfs://c6401.ambari.apache.org:8020
 2015-06-08 23:19:17,933 [init.Initialize] INFO : Accumulo data dirs are 
 [hdfs://c6401.ambari.apache.org:8020/apps/accumulo/data]
 2015-06-08 23:19:17,933 [init.Initialize] INFO : Zookeeper server is 
 c6401.ambari.apache.org:2181
 2015-06-08 23:19:17,933 [init.Initialize] INFO : Checking if Zookeeper is 
 available. If this hangs, then you need to make sure zookeeper is running
 Enter initial password for root (this may not be applicable for your security 
 setup): **
 Confirm initial password for root: **
 2015-06-08 23:19:18,661 [Configuration.deprecation] INFO : 
 dfs.replication.min is deprecated. Instead, use dfs.namenode.replication.min
 2015-06-08 23:19:18,944 [Configuration.deprecation] INFO : dfs.block.size is 
 deprecated. Instead, use dfs.blocksize
 2015-06-08 23:19:19,154 [hdfs.DFSClient] INFO : Exception in 
 createBlockOutputStream
 java.net.ConnectException: Connection refused
   at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
   at 
 sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
   at 
 org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
   at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531)
   at 
 org.apache.hadoop.hdfs.DFSOutputStream.createSocketForPipeline(DFSOutputStream.java:1575)
   at 
 org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1317)
   at 
 org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1270)
   at 
 org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:464)
 2015-06-08 23:19:19,158 [hdfs.DFSClient] INFO : Abandoning 
 BP-431548639-192.168.64.101-1433805216294:blk_1073741834_1010
 2015-06-08 23:19:19,172 [hdfs.DFSClient] INFO : Excluding datanode 
 DatanodeInfoWithStorage[192.168.64.101:50010,DS-3861ea49-69b6-4bc9-bcba-c81ed9585b51,DISK]
 2015-06-08 23:19:19,205 [hdfs.DFSClient] WARN : DataStreamer Exception
 org.apache.hadoop.ipc.RemoteException(java.io.IOException): File 
 /apps/accumulo/data/tables/!0/table_info/0_1.rf could only be replicated to 0 
 nodes instead of minReplication (=1).  There are 1 datanode(s) running and 1 
 node(s) are excluded in this operation.
   at 
 org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.chooseTarget4NewBlock(BlockManager.java:1551)
   at 
 org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNewBlockTargets(FSNamesystem.java:3104)
   at 
 org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:3028)
   at 
 org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.addBlock(NameNodeRpcServer.java:723)
   at 
 org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.addBlock(ClientNamenodeProtocolServerSideTranslatorPB.java:492)
   at 
 org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
   at 
 org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
   at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
   at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2081)
   at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2077)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAs(Subject.java:422)
   at 
 

[jira] [Created] (ACCUMULO-3895) Accumulo init can fail halfway through

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3895:


 Summary: Accumulo init can fail halfway through
 Key: ACCUMULO-3895
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3895
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi


I saw a situation where accumulo init exited with error code 255, the HDFS 
directories were successfully created, and security was not initialized.  The 
contents of accumulo-init.out were the following.  I realize no good can come 
of running init when there are no DataNodes, but it would be nice if init 
cleaned up after itself when it fails.
{noformat}
2015-06-08 23:19:17,930 [fs.VolumeManagerImpl] WARN : dfs.datanode.synconclose 
set to false in hdfs-site.xml: data loss is possible on hard system reset or 
power loss
2015-06-08 23:19:17,932 [init.Initialize] INFO : Hadoop Filesystem is 
hdfs://c6401.ambari.apache.org:8020
2015-06-08 23:19:17,933 [init.Initialize] INFO : Accumulo data dirs are 
[hdfs://c6401.ambari.apache.org:8020/apps/accumulo/data]
2015-06-08 23:19:17,933 [init.Initialize] INFO : Zookeeper server is 
c6401.ambari.apache.org:2181
2015-06-08 23:19:17,933 [init.Initialize] INFO : Checking if Zookeeper is 
available. If this hangs, then you need to make sure zookeeper is running
Enter initial password for root (this may not be applicable for your security 
setup): **
Confirm initial password for root: **
2015-06-08 23:19:18,661 [Configuration.deprecation] INFO : dfs.replication.min 
is deprecated. Instead, use dfs.namenode.replication.min
2015-06-08 23:19:18,944 [Configuration.deprecation] INFO : dfs.block.size is 
deprecated. Instead, use dfs.blocksize
2015-06-08 23:19:19,154 [hdfs.DFSClient] INFO : Exception in 
createBlockOutputStream
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at 
org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:531)
at 
org.apache.hadoop.hdfs.DFSOutputStream.createSocketForPipeline(DFSOutputStream.java:1575)
at 
org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.createBlockOutputStream(DFSOutputStream.java:1317)
at 
org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.nextBlockOutputStream(DFSOutputStream.java:1270)
at 
org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer.run(DFSOutputStream.java:464)
2015-06-08 23:19:19,158 [hdfs.DFSClient] INFO : Abandoning 
BP-431548639-192.168.64.101-1433805216294:blk_1073741834_1010
2015-06-08 23:19:19,172 [hdfs.DFSClient] INFO : Excluding datanode 
DatanodeInfoWithStorage[192.168.64.101:50010,DS-3861ea49-69b6-4bc9-bcba-c81ed9585b51,DISK]
2015-06-08 23:19:19,205 [hdfs.DFSClient] WARN : DataStreamer Exception
org.apache.hadoop.ipc.RemoteException(java.io.IOException): File 
/apps/accumulo/data/tables/!0/table_info/0_1.rf could only be replicated to 0 
nodes instead of minReplication (=1).  There are 1 datanode(s) running and 1 
node(s) are excluded in this operation.
at 
org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.chooseTarget4NewBlock(BlockManager.java:1551)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNewBlockTargets(FSNamesystem.java:3104)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:3028)
at 
org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.addBlock(NameNodeRpcServer.java:723)
at 
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.addBlock(ClientNamenodeProtocolServerSideTranslatorPB.java:492)
at 
org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
at 
org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:616)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:969)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2081)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2077)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at 
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2075)

at org.apache.hadoop.ipc.Client.call(Client.java:1427)
at org.apache.hadoop.ipc.Client.call(Client.java:1358)
at 
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
at com.sun.proxy.$Proxy15.addBlock(Unknown Source)
at 

[jira] [Created] (ACCUMULO-3890) Use of CredentialProvider results in a lot of NN ops

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3890:


 Summary: Use of CredentialProvider results in a lot of NN ops
 Key: ACCUMULO-3890
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3890
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.7.0, 1.6.2, 1.6.1
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0


Every time we access a sensitive property or iterate over a configuration when 
there is a CredentialProvider configured, it results in NN operations (as 
evidenced by FSNamesystem.audit logs).  I think that we could assume the 
CredentialProvider is static, read its properties once and cache them in memory 
to avoid these unnecessary reads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3883) ITs should not load default ClientConfiguration

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3883.
--
Resolution: Fixed

 ITs should not load default ClientConfiguration
 ---

 Key: ACCUMULO-3883
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3883
 Project: Accumulo
  Issue Type: Bug
  Components: test
Affects Versions: 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3883.1.patch

  Time Spent: 40m
  Remaining Estimate: 0h

 In StandaloneAccumuloClusterConfiguration, this appears not to work as 
 expected, nor is it necessary:
 {noformat}
 this.clientConf = ClientConfiguration.loadDefault();
 try {
   clientConf.addConfiguration(new ClientConfiguration(clientConfFile));
 } catch (ConfigurationException e) {
   throw new RuntimeException(Failed to load client configuration from  
 + clientConfFile);
 }
 {noformat}
 In general ITs should not load the default configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3883) StandaloneAccumuloClusterConfiguration loads ClientConfiguration badly

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3883:
-
Attachment: ACCUMULO-3883.1.patch

 StandaloneAccumuloClusterConfiguration loads ClientConfiguration badly
 --

 Key: ACCUMULO-3883
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3883
 Project: Accumulo
  Issue Type: Bug
  Components: test
Affects Versions: 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3883.1.patch


 This appears not to work as expected, nor is it necessary:
 {noformat}
 this.clientConf = ClientConfiguration.loadDefault();
 try {
   clientConf.addConfiguration(new ClientConfiguration(clientConfFile));
 } catch (ConfigurationException e) {
   throw new RuntimeException(Failed to load client configuration from  
 + clientConfFile);
 }
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3884) Root principal can be deleted

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3884:


 Summary: Root principal can be deleted
 Key: ACCUMULO-3884
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3884
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.7.0
Reporter: Billie Rinaldi


Not sure if this is something we need to change; but there should at least be 
some dire documentation about what happens if you delete your root principal 
without meaning it, and what it would take to recover from that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3883) StandaloneAccumuloClusterConfiguration loads ClientConfiguration badly

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3883:


 Summary: StandaloneAccumuloClusterConfiguration loads 
ClientConfiguration badly
 Key: ACCUMULO-3883
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3883
 Project: Accumulo
  Issue Type: Bug
  Components: test
Affects Versions: 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0


This appears not to work as expected, nor is it necessary:
{noformat}
this.clientConf = ClientConfiguration.loadDefault();
try {
  clientConf.addConfiguration(new ClientConfiguration(clientConfFile));
} catch (ConfigurationException e) {
  throw new RuntimeException(Failed to load client configuration from  + 
clientConfFile);
}
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3883) ITs should not load default ClientConfiguration

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3883:
-
Description: 
In StandaloneAccumuloClusterConfiguration, this appears not to work as 
expected, nor is it necessary:
{noformat}
this.clientConf = ClientConfiguration.loadDefault();
try {
  clientConf.addConfiguration(new ClientConfiguration(clientConfFile));
} catch (ConfigurationException e) {
  throw new RuntimeException(Failed to load client configuration from  + 
clientConfFile);
}
{noformat}

In general ITs should not load the default configuration.

  was:
This appears not to work as expected, nor is it necessary:
{noformat}
this.clientConf = ClientConfiguration.loadDefault();
try {
  clientConf.addConfiguration(new ClientConfiguration(clientConfFile));
} catch (ConfigurationException e) {
  throw new RuntimeException(Failed to load client configuration from  + 
clientConfFile);
}
{noformat}

Summary: ITs should not load default ClientConfiguration  (was: 
StandaloneAccumuloClusterConfiguration loads ClientConfiguration badly)

The only other place I see loading the default at the moment is 
TransportCachingIT.

 ITs should not load default ClientConfiguration
 ---

 Key: ACCUMULO-3883
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3883
 Project: Accumulo
  Issue Type: Bug
  Components: test
Affects Versions: 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3883.1.patch

  Time Spent: 20m
  Remaining Estimate: 0h

 In StandaloneAccumuloClusterConfiguration, this appears not to work as 
 expected, nor is it necessary:
 {noformat}
 this.clientConf = ClientConfiguration.loadDefault();
 try {
   clientConf.addConfiguration(new ClientConfiguration(clientConfFile));
 } catch (ConfigurationException e) {
   throw new RuntimeException(Failed to load client configuration from  
 + clientConfFile);
 }
 {noformat}
 In general ITs should not load the default configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3862) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3862.
--
Resolution: Fixed

 Improve how AsyncSpanReceiver drops short spans
 ---

 Key: ACCUMULO-3862
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3862
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3862.1.patch, ACCUMULO-3862.2.patch, 
 ACCUMULO-3862.3.patch

  Time Spent: 40m
  Remaining Estimate: 0h

 It just occurred to me that we are dropping 0ms spans when we poll the 
 sendQueue for a span to deliver via thrift.  It would cause less churn in the 
 queue if we dropped the span as soon as we received it, before inserting it 
 into the queue.
 This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
 really a concern in 1.7.0 if you are using HDFS tracing, which generates a 
 LOT of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3873) Ambari-installed client.conf not loaded by default

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14566610#comment-14566610
 ] 

Billie Rinaldi commented on ACCUMULO-3873:
--

LGTM.

 Ambari-installed client.conf not loaded by default
 --

 Key: ACCUMULO-3873
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3873
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.7.0
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Critical
 Fix For: 1.6.3, 1.7.1

 Attachments: 
 0001-ACCUMULO-3873-Add-ambari-installed-client.conf-locat.patch


 Billie did a bunch of great work to bring Accumulo into Ambari recently. In 
 working on the Hive integration again for Accumulo, I noticed that I was 
 having problems getting the client configuration file Ambari installed for me 
 picked up in Hive.
 Hive was just doing a normal
 {code}
 ClientConfiguration.loadDefault()
 {code}
 The problem is that Accumulo was looking for {{/etc/accumulo/client.conf}} 
 when Ambari has another level of directories in the path 
 {{/etc/accumulo/conf/client.conf}}.
 I believe that we should also add this to the default search path for 
 Accumulo.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3862) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3862:
-
Attachment: ACCUMULO-3862.3.patch

 Improve how AsyncSpanReceiver drops short spans
 ---

 Key: ACCUMULO-3862
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3862
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1, 1.8.0

 Attachments: ACCUMULO-3862.1.patch, ACCUMULO-3862.2.patch, 
 ACCUMULO-3862.3.patch


 It just occurred to me that we are dropping 0ms spans when we poll the 
 sendQueue for a span to deliver via thrift.  It would cause less churn in the 
 queue if we dropped the span as soon as we received it, before inserting it 
 into the queue.
 This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
 really a concern in 1.7.0 if you are using HDFS tracing, which generates a 
 LOT of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3862) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3862:
-
Attachment: ACCUMULO-3862.2.patch

 Improve how AsyncSpanReceiver drops short spans
 ---

 Key: ACCUMULO-3862
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3862
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1

 Attachments: ACCUMULO-3862.1.patch, ACCUMULO-3862.2.patch


 It just occurred to me that we are dropping 0ms spans when we poll the 
 sendQueue for a span to deliver via thrift.  It would cause less churn in the 
 queue if we dropped the span as soon as we received it, before inserting it 
 into the queue.
 This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
 really a concern in 1.7.0 if you are using HDFS tracing, which generates a 
 LOT of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3862) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3862:


 Summary: Improve how AsyncSpanReceiver drops short spans
 Key: ACCUMULO-3862
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3862
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.7.0, 1.6.2, 1.6.1, 1.6.0, 1.5.2, 1.5.1, 1.5.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1


It just occurred to me that we are dropping 0ms spans when we poll the 
sendQueue for a span to deliver via thrift.  It would cause less churn in the 
queue if we dropped the span as soon as we received it, before inserting it 
into the queue.

This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
really a concern in 1.7.0 if you are using HDFS tracing, which generates a LOT 
of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3863) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3863:


 Summary: Improve how AsyncSpanReceiver drops short spans
 Key: ACCUMULO-3863
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3863
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.7.0, 1.6.2, 1.6.1, 1.6.0, 1.5.2, 1.5.1, 1.5.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1


It just occurred to me that we are dropping 0ms spans when we poll the 
sendQueue for a span to deliver via thrift.  It would cause less churn in the 
queue if we dropped the span as soon as we received it, before inserting it 
into the queue.

This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
really a concern in 1.7.0 if you are using HDFS tracing, which generates a LOT 
of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3863) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3863.
--

Sorry, having some issues with JIRA.

 Improve how AsyncSpanReceiver drops short spans
 ---

 Key: ACCUMULO-3863
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3863
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1


 It just occurred to me that we are dropping 0ms spans when we poll the 
 sendQueue for a span to deliver via thrift.  It would cause less churn in the 
 queue if we dropped the span as soon as we received it, before inserting it 
 into the queue.
 This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
 really a concern in 1.7.0 if you are using HDFS tracing, which generates a 
 LOT of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3862) Improve how AsyncSpanReceiver drops short spans

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3862:
-
Attachment: ACCUMULO-3862.1.patch

 Improve how AsyncSpanReceiver drops short spans
 ---

 Key: ACCUMULO-3862
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3862
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.6.3, 1.7.1

 Attachments: ACCUMULO-3862.1.patch


 It just occurred to me that we are dropping 0ms spans when we poll the 
 sendQueue for a span to deliver via thrift.  It would cause less churn in the 
 queue if we dropped the span as soon as we received it, before inserting it 
 into the queue.
 This is already fixed in 1.6.3 which no longer drops 0ms spans.  It is only 
 really a concern in 1.7.0 if you are using HDFS tracing, which generates a 
 LOT of 0ms spans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-925) Launch scripts should use a PIDfile

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-925:

Attachment: ACCUMULO-925.1.patch

Initial patch (does not attempt to address bullet 3).

 Launch scripts should use a PIDfile
 ---

 Key: ACCUMULO-925
 URL: https://issues.apache.org/jira/browse/ACCUMULO-925
 Project: Accumulo
  Issue Type: Improvement
  Components: scripts
Reporter: Christopher Tubbs
Assignee: Billie Rinaldi
 Attachments: ACCUMULO-925.1.patch


 Start scripts should create PIDfiles to store the PID of running processes in 
 a well known location (example: /var/run/accumulo/tserver.pid or 
 $ACCUMULO_HOME/tserver.pid), for the following benefits:
 # Identify running services on a machine without executing and parsing the 
 system process list, so stop scripts can kill them when they are unresponsive.
 # Prevent multiple instances of the same application from starting up (an 
 environment variable for the location of the PIDfile can be used to allow 
 multiple instances if it is desirable to do so).
 # Potentially provide an alternate mechanism for terminating a process by 
 deleting its PIDfile rather than its lock in Zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ACCUMULO-925) Launch scripts should use a PIDfile

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi reassigned ACCUMULO-925:
---

Assignee: Billie Rinaldi

 Launch scripts should use a PIDfile
 ---

 Key: ACCUMULO-925
 URL: https://issues.apache.org/jira/browse/ACCUMULO-925
 Project: Accumulo
  Issue Type: Improvement
  Components: scripts
Reporter: Christopher Tubbs
Assignee: Billie Rinaldi

 Start scripts should create PIDfiles to store the PID of running processes in 
 a well known location (example: /var/run/accumulo/tserver.pid or 
 $ACCUMULO_HOME/tserver.pid), for the following benefits:
 # Identify running services on a machine without executing and parsing the 
 system process list, so stop scripts can kill them when they are unresponsive.
 # Prevent multiple instances of the same application from starting up (an 
 environment variable for the location of the PIDfile can be used to allow 
 multiple instances if it is desirable to do so).
 # Potentially provide an alternate mechanism for terminating a process by 
 deleting its PIDfile rather than its lock in Zookeeper.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3827) Default store types for monitor SSL are broken

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3827:


 Summary: Default store types for monitor SSL are broken
 Key: ACCUMULO-3827
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3827
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1


Not sure why I left the default types an empty string, because that doesn't 
actually work.  They should be jks.  A workaround for 1.7.0 is to set the 
monitor.ssl.keyStoreType and monitor.ssl.trustStoreType properties explicitly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3827) Default store types for monitor SSL are broken

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3827.
--
Resolution: Fixed

 Default store types for monitor SSL are broken
 --

 Key: ACCUMULO-3827
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3827
 Project: Accumulo
  Issue Type: Bug
Affects Versions: 1.7.0
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.1

  Time Spent: 10m
  Remaining Estimate: 0h

 Not sure why I left the default types an empty string, because that doesn't 
 actually work.  They should be jks.  A workaround for 1.7.0 is to set the 
 monitor.ssl.keyStoreType and monitor.ssl.trustStoreType properties explicitly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3817) Accumulo metrics improvements

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3817:


 Summary: Accumulo metrics improvements
 Key: ACCUMULO-3817
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3817
 Project: Accumulo
  Issue Type: Improvement
Reporter: Billie Rinaldi
 Fix For: 1.8.0


I've been taking a look at the hadoop metrics2 metrics Accumulo is providing 
and trying to make interesting graphs out of them.  Most of the tserver metrics 
are provided as avg/min/max/counts, which might be okay for heatmaps, but 
aren't good for aggregating over to provide a graph for an entire instance.  
Also, most of the metrics we're using to display useful information on the 
monitor page don't appear in the metrics2 collection.  The master doesn't have 
any metrics at all beyond thrift and replication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3779) Shell fails to connect to ZooKeeper when client.conf doesn't exist

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14533098#comment-14533098
 ] 

Billie Rinaldi commented on ACCUMULO-3779:
--

bq. I don't remember completely dropping support for fallback to using 
accumulo-site.xml

We didn't drop it; there seems to be a bug in how it's implemented.

 Shell fails to connect to ZooKeeper when client.conf doesn't exist
 --

 Key: ACCUMULO-3779
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3779
 Project: Accumulo
  Issue Type: Bug
  Components: shell
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
 Fix For: 1.7.0


 Stood up 1.7.0, forgot to make a client.conf (there wasn't a template 
 included in the example confs).
 Tried to connect to the shell and it just timed out trying to talk to 
 ZooKeeper at the default host of localhost:2181. I feel like this is a 
 regression against 1.6 because things used to attempt to work by trying to 
 read accumulo-site.xml.
 If we are intentionally not supporting automatic fallback to 
 accumulo-site.xml, we should have a log message that informs the user when we 
 construct a ClientConfiguration without any actual configuration (as that's 
 likely an error).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3779) Shell fails to connect to ZooKeeper when client.conf doesn't exist

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3779:
-
Affects Version/s: (was: 1.6.2)
   (was: 1.6.1)
   (was: 1.6.0)

 Shell fails to connect to ZooKeeper when client.conf doesn't exist
 --

 Key: ACCUMULO-3779
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3779
 Project: Accumulo
  Issue Type: Bug
  Components: shell
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
 Fix For: 1.7.0


 Stood up 1.7.0, forgot to make a client.conf (there wasn't a template 
 included in the example confs).
 Tried to connect to the shell and it just timed out trying to talk to 
 ZooKeeper at the default host of localhost:2181. I feel like this is a 
 regression against 1.6 because things used to attempt to work by trying to 
 read accumulo-site.xml.
 If we are intentionally not supporting automatic fallback to 
 accumulo-site.xml, we should have a log message that informs the user when we 
 construct a ClientConfiguration without any actual configuration (as that's 
 likely an error).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3779) Shell fails to connect to ZooKeeper when client.conf doesn't exist

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532650#comment-14532650
 ] 

Billie Rinaldi commented on ACCUMULO-3779:
--

Looking at Shell.getZooInstance, it doesn't seem like this behavior has changed 
since 1.6, so it might be a bug in earlier versions too.  In particular:
{noformat}
if (instanceName == null || keepers == null) {
  ... load from site conf ...
  if (keepers == null) {
keepers = conf.get(Property.INSTANCE_ZK_HOST);
  }
}
{noformat}
It seems to me that if (keepers == null) should be
{noformat}
if (keepers == null || 
keepers.equals(ClientProperty.INSTANCE_ZK_HOST.getDefaultValue()))
{noformat}


 Shell fails to connect to ZooKeeper when client.conf doesn't exist
 --

 Key: ACCUMULO-3779
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3779
 Project: Accumulo
  Issue Type: Bug
  Components: shell
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Blocker
 Fix For: 1.7.0


 Stood up 1.7.0, forgot to make a client.conf (there wasn't a template 
 included in the example confs).
 Tried to connect to the shell and it just timed out trying to talk to 
 ZooKeeper at the default host of localhost:2181. I feel like this is a 
 regression against 1.6 because things used to attempt to work by trying to 
 read accumulo-site.xml.
 If we are intentionally not supporting automatic fallback to 
 accumulo-site.xml, we should have a log message that informs the user when we 
 construct a ClientConfiguration without any actual configuration (as that's 
 likely an error).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3760) Make RemoteSpan more compatible with 1.6 version

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3760.
--
Resolution: Fixed

Also remove some unneeded methods from o.a.a.core.trace.Span.

 Make RemoteSpan more compatible with 1.6 version
 

 Key: ACCUMULO-3760
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3760
 Project: Accumulo
  Issue Type: Sub-task
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
  Labels: summit2015
 Fix For: 1.7.0

  Time Spent: 20m
  Remaining Estimate: 0h

 The k/v data in RemoteSpan was changed to mapbinary, binary unnecessarily 
 -- let's change it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3551) Write 1.7.0 upgrade instructions

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518260#comment-14518260
 ] 

Billie Rinaldi commented on ACCUMULO-3551:
--

Given the changes in RemoteSpan, I expect the trace table data will not be 
compatible.

 Write 1.7.0 upgrade instructions
 

 Key: ACCUMULO-3551
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3551
 Project: Accumulo
  Issue Type: Bug
Reporter: Keith Turner
Priority: Blocker
  Labels: summit2015
 Fix For: 1.7.0


 Need to write the 1.7.0 upgrade instructions.  
 The [code review|https://reviews.apache.org/r/30236/] for ACCUMULO-1515 has 
 some discussion about where these instructions should go.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3760) Make RemoteSpan more compatible with 1.6 version

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3760:


 Summary: Make RemoteSpan more compatible with 1.6 version
 Key: ACCUMULO-3760
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3760
 Project: Accumulo
  Issue Type: Sub-task
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.0


The k/v data in RemoteSpan was changed to mapbinary, binary unnecessarily -- 
let's change it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3760) Make RemoteSpan more compatible with 1.6 version

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3760:
-
Labels: summit2015  (was: )

 Make RemoteSpan more compatible with 1.6 version
 

 Key: ACCUMULO-3760
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3760
 Project: Accumulo
  Issue Type: Sub-task
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
  Labels: summit2015
 Fix For: 1.7.0


 The k/v data in RemoteSpan was changed to mapbinary, binary unnecessarily 
 -- let's change it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3742.
--
Resolution: Fixed

I think it's done; just left it open for a bit in case we found any other bugs 
it introduced.

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 1.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Status: Reopened  (was: Reopened)

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 1.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14509677#comment-14509677
 ] 

Billie Rinaldi commented on ACCUMULO-3742:
--

Sigh, I started using this useful-sounding method setDelimiterParsingDisabled, 
but it turns out it results in different behavior than disabling delimiter 
parsing by setting the list delimiter to \0.  It's no longer unescaping escape 
characters.  I'll have to switch it back to setListDelimiter.  Thanks [~elserj] 
for noticing there was a problem.

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 1h 10m
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Fix Version/s: (was: 1.6.3)

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 1.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3746) ClientConfiguration.getAllPropertiesWithPrefix doesn't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3746.
--
Resolution: Fixed

 ClientConfiguration.getAllPropertiesWithPrefix doesn't work
 ---

 Key: ACCUMULO-3746
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3746
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0

  Time Spent: 20m
  Remaining Estimate: 0h

 I think I introduced this method for trace.span.receiver.*, and didn't write 
 a test for it.  My mistake.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507465#comment-14507465
 ] 

Billie Rinaldi commented on ACCUMULO-3742:
--

That's fine with me.  The warning I added is being triggered unnecessarily at 
times, so that needs to be fixed too.

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Status: Reopened  (was: Reopened)

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3746) ClientConfiguration.getAllPropertiesWithPrefix doesn't work

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3746:


 Summary: ClientConfiguration.getAllPropertiesWithPrefix doesn't 
work
 Key: ACCUMULO-3746
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3746
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0


I think I introduced this method for trace.span.receiver.*, and didn't write a 
test for it.  My mistake.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Attachment: ACCUMULO-3742.2.patch

Found a few more things to fix as I worked through the branches; master patch 
looks more like the attached.

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3742.
--
Resolution: Fixed

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch, ACCUMULO-3742.2.patch

  Time Spent: 0.5h
  Remaining Estimate: 0h

 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3741) Reduce incompatibilities with htrace 3.2.0-incubating

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3741:
-
Attachment: ACCUMULO-3741.2.patch

 Reduce incompatibilities with htrace 3.2.0-incubating
 -

 Key: ACCUMULO-3741
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3741
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Attachments: ACCUMULO-3741.1.patch, ACCUMULO-3741.2.patch


 HTrace 3.2.0-incubating is coming out soon and there are some significant 
 differences in its API.  Ideally we would like Accumulo to work with either 
 version.  Differences include:
 * no Trace.setProcessId method
 * process ID is handled differently now; it defaults to name/IP, while before 
 Accumulo tracked IP manually
 * SpanReceivers are expected to set process ID if it is not provided
 * return type of Span.getKVAnnotations changed from Mapbyte[],byte[] to 
 MapString,String
 * Spans can now have multiple parents (although none do yet) and getParentId 
 has been replaced by getParents which returns a list of longs
 * multiple parents means there is no longer a fixed root span ID; root spans 
 just have an empty list of parents



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Affects Version/s: 1.6.2

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch


 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Fix Version/s: 1.6.3

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Affects Versions: 1.6.2
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0, 1.6.3

 Attachments: ACCUMULO-3742.1.patch


 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3742:
-
Attachment: ACCUMULO-3742.1.patch

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0

 Attachments: ACCUMULO-3742.1.patch


 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503623#comment-14503623
 ] 

Billie Rinaldi commented on ACCUMULO-3742:
--

Yeah, we use it 5 or so different places.

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Blocker
 Fix For: 1.7.0


 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503590#comment-14503590
 ] 

Billie Rinaldi commented on ACCUMULO-3742:
--

Mostly we are using PropertiesConfiguration to read a config file.  We could 
introduce a new constructor to ClientConfiguration that takes a config file and 
handles it properly (see below), although that would not prevent people from 
using it the broken way.
{noformat}
  public ClientConfiguration(String configFile) throws ConfigurationException {
this(new PropertiesConfiguration(), configFile);
  }

  private ClientConfiguration(PropertiesConfiguration propertiesConfiguration, 
String configFile) throws ConfigurationException {
super(propertiesConfiguration);
// Don't do list interpolation
propertiesConfiguration.setListDelimiter('\0');
propertiesConfiguration.load(configFile);
  }
{noformat}

 Multiple-valued client properties don't work
 

 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.0


 When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
 the PropertiesConfiguration has already interpreted any multi-valued 
 properties as lists, so when we read those properties as strings we only get 
 the first value in the list.  This affects instance.zookeeper.host and 
 trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3742) Multiple-valued client properties don't work

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3742:


 Summary: Multiple-valued client properties don't work
 Key: ACCUMULO-3742
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3742
 Project: Accumulo
  Issue Type: Bug
  Components: client
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.0


When we use the pattern new ClientConfiguration(new PropertiesConfiguration), 
the PropertiesConfiguration has already interpreted any multi-valued properties 
as lists, so when we read those properties as strings we only get the first 
value in the list.  This affects instance.zookeeper.host and 
trace.span.receivers.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3741) Reduce incompatibilities with htrace 3.2.0-incubating

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3741:


 Summary: Reduce incompatibilities with htrace 3.2.0-incubating
 Key: ACCUMULO-3741
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3741
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi


HTrace 3.2.0-incubating is coming out soon and there are some significant 
differences in its API.  Ideally we would like Accumulo to work with either 
version.  Differences include:
* no Trace.setProcessId method
* process ID is handled differently now; it defaults to name/IP, while before 
Accumulo tracked IP manually
* SpanReceivers are expected to set process ID if it is not provided
* return type of Span.getKVAnnotations changed from Mapbyte[],byte[] to 
MapString,String
* Spans can now have multiple parents (although none do yet) and getParentId 
has been replaced by getParents which returns a list of longs
* multiple parents means there is no longer a fixed root span ID; root spans 
just have an empty list of parents



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3741) Reduce incompatibilities with htrace 3.2.0-incubating

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500995#comment-14500995
 ] 

Billie Rinaldi commented on ACCUMULO-3741:
--

I do not expect to switch to version 3.2.0-incubating for Accumulo 1.7.0.  
3.2.0-incubating has not actually been released yet, but it's being discussed.  
However, I'd like to evaluate the changes that would be necessary and see if it 
would make sense to bring any of them into 1.7.0.  For example, I think the 
thrift object RemoteSpan will need to be changed, and in some ways it would be 
changing back to how it was in 1.6.0.  It would be nice to avoid switching back 
and forth.  I'll attach the patch I have so far, as a preview.  It compiles 
with both versions of htrace, but I am only just starting to test it now.

 Reduce incompatibilities with htrace 3.2.0-incubating
 -

 Key: ACCUMULO-3741
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3741
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi

 HTrace 3.2.0-incubating is coming out soon and there are some significant 
 differences in its API.  Ideally we would like Accumulo to work with either 
 version.  Differences include:
 * no Trace.setProcessId method
 * process ID is handled differently now; it defaults to name/IP, while before 
 Accumulo tracked IP manually
 * SpanReceivers are expected to set process ID if it is not provided
 * return type of Span.getKVAnnotations changed from Mapbyte[],byte[] to 
 MapString,String
 * Spans can now have multiple parents (although none do yet) and getParentId 
 has been replaced by getParents which returns a list of longs
 * multiple parents means there is no longer a fixed root span ID; root spans 
 just have an empty list of parents



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ACCUMULO-3741) Reduce incompatibilities with htrace 3.2.0-incubating

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi updated ACCUMULO-3741:
-
Attachment: ACCUMULO-3741.1.patch

 Reduce incompatibilities with htrace 3.2.0-incubating
 -

 Key: ACCUMULO-3741
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3741
 Project: Accumulo
  Issue Type: Bug
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Attachments: ACCUMULO-3741.1.patch


 HTrace 3.2.0-incubating is coming out soon and there are some significant 
 differences in its API.  Ideally we would like Accumulo to work with either 
 version.  Differences include:
 * no Trace.setProcessId method
 * process ID is handled differently now; it defaults to name/IP, while before 
 Accumulo tracked IP manually
 * SpanReceivers are expected to set process ID if it is not provided
 * return type of Span.getKVAnnotations changed from Mapbyte[],byte[] to 
 MapString,String
 * Spans can now have multiple parents (although none do yet) and getParentId 
 has been replaced by getParents which returns a list of longs
 * multiple parents means there is no longer a fixed root span ID; root spans 
 just have an empty list of parents



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3725) Majc trace tacked onto minc trace

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14494522#comment-14494522
 ] 

Billie Rinaldi commented on ACCUMULO-3725:
--

I'm going to commit a patch that stops the minc root span before the major 
compaction is initiated.  This will give the major compaction a new parent 
instead of having the minc root span be its parent.  The minc span still needs 
to be stopped in the finally block, in case an error occurs before it is 
stopped in the try block.  Stopping more than once should have no effect.

 Majc trace tacked onto minc trace
 -

 Key: ACCUMULO-3725
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3725
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.0


 [~elserj] noticed an issue where a minorCompaction trace of length 10295 ms 
 also contained spans for a major compaction starting at time offset 46336 ms. 
  Looking into this, it seems like MinorCompactionTask.run does the following:
 {noformat}
 start minc root span
 try {
   minor compaction
   maybe major compaction
 } finally {
   stop minc root span
 }
 {noformat}
 The major compaction is async, so it gets initiated with the minor compaction 
 span as its parent, then the minor compaction span is stopped, and at some 
 point later the major compaction occurs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3725) Majc trace tacked onto minc trace

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3725:


 Summary: Majc trace tacked onto minc trace
 Key: ACCUMULO-3725
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3725
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.0


[~elserj] noticed an issue where a minorCompaction trace of length 10295 ms 
also contained spans for a major compaction starting at time offset 46336 ms.  
Looking into this, it seems like MinorCompactionTask.run does the following:
{noformat}
start minc root span
try {
  minor compaction
  maybe major compaction
} finally {
  stop minc root span
}
{noformat}
The major compaction is async, so it gets initiated with the minor compaction 
span as its parent, then the minor compaction span is stopped, and at some 
point later the major compaction occurs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3725) Majc trace tacked onto minc trace

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3725.
--
Resolution: Fixed

 Majc trace tacked onto minc trace
 -

 Key: ACCUMULO-3725
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3725
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
 Fix For: 1.7.0

  Time Spent: 10m
  Remaining Estimate: 0h

 [~elserj] noticed an issue where a minorCompaction trace of length 10295 ms 
 also contained spans for a major compaction starting at time offset 46336 ms. 
  Looking into this, it seems like MinorCompactionTask.run does the following:
 {noformat}
 start minc root span
 try {
   minor compaction
   maybe major compaction
 } finally {
   stop minc root span
 }
 {noformat}
 The major compaction is async, so it gets initiated with the minor compaction 
 span as its parent, then the minor compaction span is stopped, and at some 
 point later the major compaction occurs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-3715) Decrease sampling percentage for tracing

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-3715.
--
Resolution: Fixed

I committed the review board patch with some additional documentation as 
requested (also found a couple of warnings to fix in the TraceTableStats class).

 Decrease sampling percentage for tracing
 

 Key: ACCUMULO-3715
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3715
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Critical
 Fix For: 1.7.0

  Time Spent: 0.5h
  Remaining Estimate: 0h

 Now that HDFS has tracing, individual traces might collect much more tracing 
 data than they did previously.  We should have a way of controlling how much 
 tracing data is collected other than just turning off HDFS tracing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ACCUMULO-3715) Decrease sampling percentage for tracing

[Billie Rinaldi (JIRA)]

Billie Rinaldi created ACCUMULO-3715:


 Summary: Decrease sampling percentage for tracing
 Key: ACCUMULO-3715
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3715
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Critical
 Fix For: 1.7.0


Now that HDFS has tracing, individual traces might collect much more tracing 
data than they did previously.  We should have a way of controlling how much 
tracing data is collected other than just turning off HDFS tracing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3715) Decrease sampling percentage for tracing

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485345#comment-14485345
 ] 

Billie Rinaldi commented on ACCUMULO-3715:
--

I suggest two approaches; one is to introduce configurable sampling parameters 
for majc, minc, gc, and replication tracing, defaulting slightly lower than 
they do now (currently trying out majc 1.0 = 0.1, minc 1.0 = 0.1, gc 0.01 
stays, replication 1.0 and 0.1 for different ops = 0.1).  Another is to 
reintroduce a minimum span length to the span receiver (in earlier versions the 
min span size was 1ms, but now it is 0ms).  This could be configured 
differently for HDFS and Accumulo, so we could keep min 0ms for Accumulo and 
set a higher min for HDFS, e.g. 1ms.

 Decrease sampling percentage for tracing
 

 Key: ACCUMULO-3715
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3715
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Critical
 Fix For: 1.7.0


 Now that HDFS has tracing, individual traces might collect much more tracing 
 data than they did previously.  We should have a way of controlling how much 
 tracing data is collected other than just turning off HDFS tracing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3715) Decrease sampling percentage for tracing

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485856#comment-14485856
 ] 

Billie Rinaldi commented on ACCUMULO-3715:
--

My idea of allowing 0ms spans for Accumulo but not HDFS won't work because most 
of the HDFS spans are in the client, meaning that they'll originate in an 
Accumulo process.  We'd be left to distinguish HDFS spans from Accumulo spans 
by inspecting the span description, which sounds bad.  This makes me think we 
should just start dropping all 0ms spans again.  We could still make it 
configurable, though.

 Decrease sampling percentage for tracing
 

 Key: ACCUMULO-3715
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3715
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Critical
 Fix For: 1.7.0


 Now that HDFS has tracing, individual traces might collect much more tracing 
 data than they did previously.  We should have a way of controlling how much 
 tracing data is collected other than just turning off HDFS tracing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-3715) Decrease sampling percentage for tracing

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14486200#comment-14486200
 ] 

Billie Rinaldi commented on ACCUMULO-3715:
--

I've posted a patch on review board.  It possible we could just start dropping 
0ms spans and not need the additional sampling configuration, so we should 
decide if we want to keep that or not.

 Decrease sampling percentage for tracing
 

 Key: ACCUMULO-3715
 URL: https://issues.apache.org/jira/browse/ACCUMULO-3715
 Project: Accumulo
  Issue Type: Bug
  Components: trace
Reporter: Billie Rinaldi
Assignee: Billie Rinaldi
Priority: Critical
 Fix For: 1.7.0


 Now that HDFS has tracing, individual traces might collect much more tracing 
 data than they did previously.  We should have a way of controlling how much 
 tracing data is collected other than just turning off HDFS tracing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ACCUMULO-2629) Traces monitor page should use a fixed width font

[Billie Rinaldi (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14483433#comment-14483433
 ] 

Billie Rinaldi commented on ACCUMULO-2629:
--

I looked into this, and it's not a variable-width font issue.  The indentation 
is not made with some number of spaces, but as multiples of 5px.  So perhaps we 
should just bump up that base value to 8px or 10px.

 Traces monitor page should use a fixed width font
 -

 Key: ACCUMULO-2629
 URL: https://issues.apache.org/jira/browse/ACCUMULO-2629
 Project: Accumulo
  Issue Type: Improvement
  Components: monitor
Reporter: John Vines
Priority: Critical
  Labels: newbie
 Fix For: 1.8.0


 The traces monitor pages provide a columnar view of data which uses 
 indentation to provide hierarchical views. This is combination with the use 
 of a variable width font make it difficult to notice levels of indentation. 
 We should use a fixed width font for that page instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ACCUMULO-2629) Traces monitor page should use more indentation

[Billie Rinaldi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Billie Rinaldi resolved ACCUMULO-2629.
--
   Resolution: Fixed
Fix Version/s: (was: 1.8.0)
   1.7.0

 Traces monitor page should use more indentation
 ---

 Key: ACCUMULO-2629
 URL: https://issues.apache.org/jira/browse/ACCUMULO-2629
 Project: Accumulo
  Issue Type: Improvement
  Components: monitor
Reporter: John Vines
Assignee: Billie Rinaldi
Priority: Critical
  Labels: newbie
 Fix For: 1.7.0

  Time Spent: 10m
  Remaining Estimate: 0h

 The traces monitor pages provide a columnar view of data which uses 
 indentation to provide hierarchical views. This is combination with the use 
 of a variable width font make it difficult to notice levels of indentation. 
 We should use a fixed width font for that page instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)