[jira] [Commented] (ACCUMULO-4159) Major compactions block bulk ingest
[ https://issues.apache.org/jira/browse/ACCUMULO-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315713#comment-17315713 ] Michael Miller commented on ACCUMULO-4159: -- [~etcoleman] Did you ever write a Test for this? I wonder if this is still an issue today. > Major compactions block bulk ingest > --- > > Key: ACCUMULO-4159 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4159 > Project: Accumulo > Issue Type: Bug > Components: core >Affects Versions: 1.6.5 >Reporter: Ed Coleman >Assignee: Ed Coleman >Priority: Major > > Major compactions seem to block bulk ingest. During a long running > compaction with a table that frequently receives bulk ingest, the bulk > ingests seem to hang until the compaction completes or is killed. > The compactions and the bulk ingest(s) do show up in the IN_PROGESS fate > transactions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-4729) MiniAccumuloCluster should have a Singleton
[ https://issues.apache.org/jira/browse/ACCUMULO-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4729. -- Resolution: Won't Do Significant progress has been made in the Accumulo code to reduce static state. This change would hinder that progress. > MiniAccumuloCluster should have a Singleton > --- > > Key: ACCUMULO-4729 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4729 > Project: Accumulo > Issue Type: New Feature > Components: mini >Affects Versions: 1.8.1 >Reporter: Jorge Machado >Priority: Minor > > As developer I would like to have something like > MiniAccumuloCluster.getInstance() > That I can share with multiple tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-1128) Throttle major compaction
[ https://issues.apache.org/jira/browse/ACCUMULO-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-1128. -- Resolution: Fixed This should be possible with the new Compaction Executors in 2.1. If there is more work needed to allow for this, please open an issue on [Github|https://github.com/apache/accumulo/issues]. > Throttle major compaction > - > > Key: ACCUMULO-1128 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1128 > Project: Accumulo > Issue Type: Improvement >Reporter: Denis Petrov >Priority: Minor > > Implement a posibility to throttle hard disk operations during major > compaction to avoid performance degradation. > Similar to Cassandra's setting 'compaction_throughput_mb_per_sec' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-2157) display scans, compactions, iterators in the monitor UI
[ https://issues.apache.org/jira/browse/ACCUMULO-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-2157. -- Resolution: Won't Fix This would require work that is out of the scope of the monitor (i.e. authenticating users, tracking user login sessions) and more appropriate for client web applications. With the REST endpoints in 2.X monitor, there is even less reason to do this type of work in the Accumulo monitor. If there is work needed to be done to the 2.x monitor REST endpoints to allow for this please feel free to open an issue on [Github|https://github.com/apache/accumulo/issues]. > display scans, compactions, iterators in the monitor UI > --- > > Key: ACCUMULO-2157 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2157 > Project: Accumulo > Issue Type: New Feature > Components: monitor >Reporter: Arshak Navruzyan >Priority: Trivial > Labels: usability > > user can get this information from the accumulo shell, it would be nice if > the output was also available in the monitor UI: > listcompactions > listiter > listscans > listshelliter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ACCUMULO-4316) Move website social buttons to footer
[ https://issues.apache.org/jira/browse/ACCUMULO-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller closed ACCUMULO-4316. > Move website social buttons to footer > - > > Key: ACCUMULO-4316 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4316 > Project: Accumulo > Issue Type: Task > Components: website >Reporter: Mike Walch >Priority: Minor > > From the review of ACCUMULO-4313, [~ctubbsii] mentioned the following... > "I think the left-side social buttons shouldn't appear on the first page > either. Instead, it should be moved to the footer. Or, at the very least, > they should be made smaller without the large text next to them (hover text > is sufficient)." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-4316) Move website social buttons to footer
[ https://issues.apache.org/jira/browse/ACCUMULO-4316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4316. -- Resolution: Fixed There are no social buttons on the left-side. The ones on the front page look fine. > Move website social buttons to footer > - > > Key: ACCUMULO-4316 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4316 > Project: Accumulo > Issue Type: Task > Components: website >Reporter: Mike Walch >Priority: Minor > > From the review of ACCUMULO-4313, [~ctubbsii] mentioned the following... > "I think the left-side social buttons shouldn't appear on the first page > either. Instead, it should be moved to the footer. Or, at the very least, > they should be made smaller without the large text next to them (hover text > is sufficient)." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-809) display Fate status in the monitor
[ https://issues.apache.org/jira/browse/ACCUMULO-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-809. - Resolution: Duplicate https://github.com/apache/accumulo/issues/1249 > display Fate status in the monitor > -- > > Key: ACCUMULO-809 > URL: https://issues.apache.org/jira/browse/ACCUMULO-809 > Project: Accumulo > Issue Type: New Feature > Components: master, monitor >Reporter: Eric C. Newton >Priority: Major > Labels: gsoc2013, mentor > > The Fate Admin class can print a crude status for the running Fate > operations. It would be nice to clean this information up and display it in > the monitor. > For example: > |Requester|Request|Table Locks|Executing|Details > |192.168.1.1|BulkImport|Index(R)|LoadFiles|Directory > /accumulo/imports/import-2010-09-01| > |192.168.1.2|RangeOp|Documents (W, waiting)| |Merging Range (200809, 200810]| > |192.168.1.1|BulkImport| |Successful|Directory > /accumulo/imports/import-2010-08-31| > | *Clear Successful Entries* | -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-4625) Monitor gets slow with lots of migrations
[ https://issues.apache.org/jira/browse/ACCUMULO-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4625. -- Resolution: Fixed This should be fixed with the new monitor in 2.x > Monitor gets slow with lots of migrations > - > > Key: ACCUMULO-4625 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4625 > Project: Accumulo > Issue Type: Bug > Components: master, monitor >Affects Versions: 1.6.6 >Reporter: Michael Wall >Priority: Major > > An anecdotal ticket until I can dig further. The monitor gets really slow > when there is a large number of migrations that need to happen. For example, > create a table. Then add 1000 splits. All tablets are assigned to one > tserver until they are migrated. May even queue up needed migrations from > other tables behind those 1000 migrations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-1463) Server components don't use standard command-line options parsing
[ https://issues.apache.org/jira/browse/ACCUMULO-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-1463. -- Resolution: Fixed We should be using jcommander for all command line parsing now. If not, an issue or PR specific to that part of the code can be opened in GitHub. > Server components don't use standard command-line options parsing > - > > Key: ACCUMULO-1463 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1463 > Project: Accumulo > Issue Type: Improvement > Components: gc, master, monitor, tserver >Reporter: Christopher Tubbs >Priority: Major > > Master/Monitor/TServer/etc. use custom command-line parsing. They should use > jcommander like the utilities. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-2348) Consolidate process ZooKeeper Lock[Watcher] code
[ https://issues.apache.org/jira/browse/ACCUMULO-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-2348. -- Resolution: Won't Do Too vague and may no longer be relevant. > Consolidate process ZooKeeper Lock[Watcher] code > > > Key: ACCUMULO-2348 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2348 > Project: Accumulo > Issue Type: Improvement > Components: gc, master, monitor, tserver >Reporter: Josh Elser >Priority: Major > > The master, monitor, GC and tserver all get a ZooLock for themselves and set > a similar Watcher. We should consolidate the watchers into one class that can > be re-used across the processes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-3206) New Public API: Approximate data counts of Tablets and Tablet Servers
[ https://issues.apache.org/jira/browse/ACCUMULO-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-3206. -- Resolution: Fixed The new Summaries that have been added in 2.x should meet this need. https://accumulo.apache.org/docs/2.x/development/summaries Any additional requirements can be opened as an issue on github. > New Public API: Approximate data counts of Tablets and Tablet Servers > - > > Key: ACCUMULO-3206 > URL: https://issues.apache.org/jira/browse/ACCUMULO-3206 > Project: Accumulo > Issue Type: New Feature > Components: client, monitor >Affects Versions: 1.6.1 >Reporter: Shana Hutchison >Priority: Minor > > The broader picture is public programmatic access to information in the > Accumulo monitor. Specifically I'm looking to obtain the number of entries > per tablet and per tablet server for a given table. The use case is to > verify that manually set (or automatically set I suppose) table splits are > effectively dividing Accumulo data among many tablets, that is, verifying > load balancing. > I wrote Accumulo 1.5 code which uses non-public API to obtain this > information in the same way the Monitor does via TabletStats. The tricky part > was cross-referencing the Metadata table to find the assignment of tablets to > tablet servers for a given table. I rewrote that code for 1.6, switching the > name of the Metadata table to "accumulo.metadata" and other associated > changes, but it would be great to make this part of the public API so that > people don't have to use non-public methods to obtain data that Accumulo has > in the Monitor and Metadata table anyway. > We could approach this by adding to the TableOperations class or something > similar. A request could go to an Accumulo master which gathers the > necessary information from the tablet servers just as the Monitor does, so > that the client does not have to do it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ACCUMULO-2403) "Master Server" and "Tables" pages in monitor are duplicative
[ https://issues.apache.org/jira/browse/ACCUMULO-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-2403: - Status: Resolved (was: Closed) > "Master Server" and "Tables" pages in monitor are duplicative > - > > Key: ACCUMULO-2403 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2403 > Project: Accumulo > Issue Type: Bug > Components: monitor >Reporter: Mike Drob >Priority: Minor > > Both the Master Server and the Tables page show a list of tables. We can't > get rid of the tables page entirely because both pages link to it for > detailed views on single tables. We can, however, remove the "tables" link > from the navigation bar on the left, or remove the table list from the master > server page. > (I prefer the first approach). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-2403) "Master Server" and "Tables" pages in monitor are duplicative
[ https://issues.apache.org/jira/browse/ACCUMULO-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-2403. -- Resolution: Not A Problem The Monitor was completely redone for 2.0. Please open an issue in Github if you think this is still an issue. https://github.com/apache/accumulo/issues > "Master Server" and "Tables" pages in monitor are duplicative > - > > Key: ACCUMULO-2403 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2403 > Project: Accumulo > Issue Type: Bug > Components: monitor >Reporter: Mike Drob >Priority: Minor > > Both the Master Server and the Tables page show a list of tables. We can't > get rid of the tables page entirely because both pages link to it for > detailed views on single tables. We can, however, remove the "tables" link > from the navigation bar on the left, or remove the table list from the master > server page. > (I prefer the first approach). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ACCUMULO-2403) "Master Server" and "Tables" pages in monitor are duplicative
[ https://issues.apache.org/jira/browse/ACCUMULO-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller closed ACCUMULO-2403. > "Master Server" and "Tables" pages in monitor are duplicative > - > > Key: ACCUMULO-2403 > URL: https://issues.apache.org/jira/browse/ACCUMULO-2403 > Project: Accumulo > Issue Type: Bug > Components: monitor >Reporter: Mike Drob >Priority: Minor > > Both the Master Server and the Tables page show a list of tables. We can't > get rid of the tables page entirely because both pages link to it for > detailed views on single tables. We can, however, remove the "tables" link > from the navigation bar on the left, or remove the table list from the master > server page. > (I prefer the first approach). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ACCUMULO-1453) Track tablet migrations and failed loads
[ https://issues.apache.org/jira/browse/ACCUMULO-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219121#comment-17219121 ] Michael Miller commented on ACCUMULO-1453: -- I believe this issue still exists in general but I know a lot of improvements were done across 1.9 release to improve recovery. bq. This would be easy to defend against by making Accumulo refuse to load key/values that are too large. I commented on ACCUMULO-1459 about large keys since I thought that was fixed. [~kturner] [~mdrob] That being said, do you think this is still worth pursuing in 2.X versions? > Track tablet migrations and failed loads > > > Key: ACCUMULO-1453 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1453 > Project: Accumulo > Issue Type: Improvement > Components: master, tserver >Affects Versions: 1.4.3, 1.5.0 >Reporter: Mike Drob >Priority: Major > > If a bad RFile or Tablet somehow gets in the system and brings down a > tserver, then as the master migrates it to other servers it will likely cause > cascading failures. > It might be a good idea to keep track of how many consecutive failures to > load there are for a given tablet, and either warn or refuse to host the > tablet if this value exceeds a given threshold. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ACCUMULO-1459) Refuse to load key/values that exceed a configured threshold
[ https://issues.apache.org/jira/browse/ACCUMULO-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219112#comment-17219112 ] Michael Miller commented on ACCUMULO-1459: -- I feel like this issue was resolved but I can't seem to find a link to the PR or release notes. Perhaps by one of these? https://accumulo.apache.org/release/accumulo-1.6.6/#analyze-key-length-to-avoid-choosing-large-keys-for-rfile-index-blocks https://issues.apache.org/jira/browse/ACCUMULO-4669 https://issues.apache.org/jira/browse/ACCUMULO-4314 > Refuse to load key/values that exceed a configured threshold > > > Key: ACCUMULO-1459 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1459 > Project: Accumulo > Issue Type: Improvement >Reporter: Keith Turner >Priority: Major > > In the interest of keeping tablet server from crashing w/ OOME, Accumulo > could fail any scans or compactions that try to read a key/value which > exceeds a configurable threshold. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (ACCUMULO-2792) SetGoalState should be made an admin command
[
https://issues.apache.org/jira/browse/ACCUMULO-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller closed ACCUMULO-2792.
> SetGoalState should be made an admin command
>
>
> Key: ACCUMULO-2792
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2792
> Project: Accumulo
> Issue Type: Improvement
> Components: master
>Affects Versions: 1.6.0
>Reporter: Vikram Srivastava
>Priority: Major
>
> Currently if we want to start master after calling "admin stopAll", we need
> to call this explicitly before starting master:
> {noformat}
> bin/accumulo org.apache.accumulo.master.state.SetGoalState NORMAL
> {noformat}
> SetGoalState was moved to another package between 1.4 and 1.6. Users with
> scripts would run into trouble figuring this out. It'd be nice to have this
> as an admin command like:
> {noformat}
> bin/accumulo admin setMasterGoalState NORMAL
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-2792) SetGoalState should be made an admin command
[
https://issues.apache.org/jira/browse/ACCUMULO-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller resolved ACCUMULO-2792.
--
Resolution: Resolved
I am marking this resolved (see previous comment). If there is anything you
want done for 2.X please open an issue on
https://github.com/apache/accumulo/issues
> SetGoalState should be made an admin command
>
>
> Key: ACCUMULO-2792
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2792
> Project: Accumulo
> Issue Type: Improvement
> Components: master
>Affects Versions: 1.6.0
>Reporter: Vikram Srivastava
>Priority: Major
>
> Currently if we want to start master after calling "admin stopAll", we need
> to call this explicitly before starting master:
> {noformat}
> bin/accumulo org.apache.accumulo.master.state.SetGoalState NORMAL
> {noformat}
> SetGoalState was moved to another package between 1.4 and 1.6. Users with
> scripts would run into trouble figuring this out. It'd be nice to have this
> as an admin command like:
> {noformat}
> bin/accumulo admin setMasterGoalState NORMAL
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ACCUMULO-2792) SetGoalState should be made an admin command
[
https://issues.apache.org/jira/browse/ACCUMULO-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219096#comment-17219096
]
Michael Miller commented on ACCUMULO-2792:
--
The command
{noformat}
"${bin}/accumulo" org.apache.accumulo.master.state.SetGoalState NORMAL
{noformat}
is automatically called by the "accumulo-service" script in 2.X. I don't think
this is needed anymore.
> SetGoalState should be made an admin command
>
>
> Key: ACCUMULO-2792
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2792
> Project: Accumulo
> Issue Type: Improvement
> Components: master
>Affects Versions: 1.6.0
>Reporter: Vikram Srivastava
>Priority: Major
>
> Currently if we want to start master after calling "admin stopAll", we need
> to call this explicitly before starting master:
> {noformat}
> bin/accumulo org.apache.accumulo.master.state.SetGoalState NORMAL
> {noformat}
> SetGoalState was moved to another package between 1.4 and 1.6. Users with
> scripts would run into trouble figuring this out. It'd be nice to have this
> as an admin command like:
> {noformat}
> bin/accumulo admin setMasterGoalState NORMAL
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-1455) Collapse stack traces in log messages in the monitor
[ https://issues.apache.org/jira/browse/ACCUMULO-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-1455. -- Resolution: Fixed Fixed in https://github.com/apache/accumulo/pull/688 > Collapse stack traces in log messages in the monitor > > > Key: ACCUMULO-1455 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1455 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.5.0 >Reporter: Mike Drob >Priority: Major > Labels: javascript > > It would be nice to be able to collapse the stack traces from log messages on > the monitor page. All stack traces should start collapsed on an initial > page-load, but should persist the open/close state across refreshes. > They contain lots of useful information, but it is only interesting if you've > never seen that error before. Especially if the same error occurs across > multiple tservers, the full stack is no longer useful and just wastes > vertical space on the screen. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ACCUMULO-1455) Collapse stack traces in log messages in the monitor
[ https://issues.apache.org/jira/browse/ACCUMULO-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17067982#comment-17067982 ] Michael Miller commented on ACCUMULO-1455: -- Fixed in the 2.x Monitor. > Collapse stack traces in log messages in the monitor > > > Key: ACCUMULO-1455 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1455 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.5.0 >Reporter: Mike Drob >Priority: Major > Labels: javascript > > It would be nice to be able to collapse the stack traces from log messages on > the monitor page. All stack traces should start collapsed on an initial > page-load, but should persist the open/close state across refreshes. > They contain lots of useful information, but it is only interesting if you've > never seen that error before. Especially if the same error occurs across > multiple tservers, the full stack is no longer useful and just wastes > vertical space on the screen. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-4377) Document and add test for Key constructors copy behavior
[ https://issues.apache.org/jira/browse/ACCUMULO-4377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4377. -- Resolution: Duplicate https://github.com/apache/accumulo/issues/1104 > Document and add test for Key constructors copy behavior > > > Key: ACCUMULO-4377 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4377 > Project: Accumulo > Issue Type: Improvement >Reporter: Keith Turner >Priority: Major > > While looking at [Github PR #125|https://github.com/apache/accumulo/pull/125] > I thought it was nice that the new constructors documented the copy behavior. > It would be nice to update the javadoc for the constructors that existed > before the PR to mention the copy behavior. > Also all of the constructors copy behavior should be tested in KeyTest.java. > Should do things like pass in byte array to constructor, modify bye array, > verify Key does not reflect changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4806. -- Resolution: Fixed > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16821860#comment-16821860 ] Michael Miller commented on ACCUMULO-4806: -- I believe this is completed. Any follow on work we can open up a github issue. > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4621) Refactor hot methods for JIT optimization
[
https://issues.apache.org/jira/browse/ACCUMULO-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820484#comment-16820484
]
Michael Miller commented on ACCUMULO-4621:
--
Duplicated in Github for 2.1 [https://github.com/apache/accumulo/issues/1099]
> Refactor hot methods for JIT optimization
> -
>
> Key: ACCUMULO-4621
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4621
> Project: Accumulo
> Issue Type: Improvement
> Components: client, fate, tserver
>Reporter: Michael Miller
>Priority: Major
>
> I did some analysis of how well the JIT compiler optimizes Accumulo code by
> running tests locally in JMH and against a single local instance of Uno. To
> print what the JIT compiler was doing, I used the following java options:
> {code}
> -XX:+PrintCompilation
> -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintInlining
> {code}
> Then I would grep the output for "accumulo" and "hot method too big". Here
> is the list of methods I compiled from the tests I did on both client and
> server.:
> {code}
> org.apache.accumulo.core.client.impl.TabletLocatorImpl::processInvalidated
> org.apache.accumulo.core.client.impl.ThriftScanner::scan
> org.apache.accumulo.core.data.Key::equals
> org.apache.accumulo.core.data.thrift.TMutation$TMutationStandardScheme::read
> org.apache.accumulo.core.file.rfile.RFile$LocalityGroupReader::_seek
> org.apache.accumulo.core.file.rfile.RelativeKey::
> org.apache.accumulo.core.file.rfile.RelativeKey::readFields
> org.apache.accumulo.core.security.ColumnVisibility$ColumnVisibilityParser::parse_
> org.apache.accumulo.fate.zookeeper.ZooCache$2::run
> org.apache.accumulo.server.constraints.MetadataConstraints::check
> org.apache.accumulo.server.master.LiveTServerSet::checkServer
> org.apache.accumulo.tserver.FileManager::reserveReaders
> org.apache.accumulo.tserver.constraints.ConstraintChecker::check
> org.apache.accumulo.tserver.scan.NextBatchTask::run
> org.apache.accumulo.tserver.tablet.ScanDataSource::createIterator
> org.apache.accumulo.tserver.tablet.Scanner::read
> {code}
> This work was inspired by this blog post:
> https://techblug.wordpress.com/2013/08/19/java-jit-compiler-inlining/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4621) Refactor hot methods for JIT optimization
[
https://issues.apache.org/jira/browse/ACCUMULO-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller resolved ACCUMULO-4621.
--
Resolution: Duplicate
Fix Version/s: (was: 2.0.0)
> Refactor hot methods for JIT optimization
> -
>
> Key: ACCUMULO-4621
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4621
> Project: Accumulo
> Issue Type: Improvement
> Components: client, fate, tserver
>Reporter: Michael Miller
>Priority: Major
>
> I did some analysis of how well the JIT compiler optimizes Accumulo code by
> running tests locally in JMH and against a single local instance of Uno. To
> print what the JIT compiler was doing, I used the following java options:
> {code}
> -XX:+PrintCompilation
> -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintInlining
> {code}
> Then I would grep the output for "accumulo" and "hot method too big". Here
> is the list of methods I compiled from the tests I did on both client and
> server.:
> {code}
> org.apache.accumulo.core.client.impl.TabletLocatorImpl::processInvalidated
> org.apache.accumulo.core.client.impl.ThriftScanner::scan
> org.apache.accumulo.core.data.Key::equals
> org.apache.accumulo.core.data.thrift.TMutation$TMutationStandardScheme::read
> org.apache.accumulo.core.file.rfile.RFile$LocalityGroupReader::_seek
> org.apache.accumulo.core.file.rfile.RelativeKey::
> org.apache.accumulo.core.file.rfile.RelativeKey::readFields
> org.apache.accumulo.core.security.ColumnVisibility$ColumnVisibilityParser::parse_
> org.apache.accumulo.fate.zookeeper.ZooCache$2::run
> org.apache.accumulo.server.constraints.MetadataConstraints::check
> org.apache.accumulo.server.master.LiveTServerSet::checkServer
> org.apache.accumulo.tserver.FileManager::reserveReaders
> org.apache.accumulo.tserver.constraints.ConstraintChecker::check
> org.apache.accumulo.tserver.scan.NextBatchTask::run
> org.apache.accumulo.tserver.tablet.ScanDataSource::createIterator
> org.apache.accumulo.tserver.tablet.Scanner::read
> {code}
> This work was inspired by this blog post:
> https://techblug.wordpress.com/2013/08/19/java-jit-compiler-inlining/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4513) Master hangs if shutdown requested while in state "HAS_LOCK"
[ https://issues.apache.org/jira/browse/ACCUMULO-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820432#comment-16820432 ] Michael Miller commented on ACCUMULO-4513: -- I am unable to reproduce this so closing the ticket. If you see it in 1.8 or 1.9, please feel free to open a GitHub issue. > Master hangs if shutdown requested while in state "HAS_LOCK" > > > Key: ACCUMULO-4513 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4513 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.6, 1.7.2 >Reporter: John Vines >Priority: Critical > > The StatusThread.run() method does not have any means to change the masters > state out of HAS_LOCK when CLEAN_STOP is requested, which can cause the > master to get perpetually stuck > Additionally, because the master never hit the NORMAL state, the main > Master.run() was jammed at waitForMetadataUpgrade.await() so the thrift > server was never started and shutdown couldn't be issued directly (not > entirely confident that would have actually fixed anything though this is > contrary to the the state transition chart which says we can go from > HAVE_LOCK->STOP) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4513) Master hangs if shutdown requested while in state "HAS_LOCK"
[ https://issues.apache.org/jira/browse/ACCUMULO-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4513. -- Resolution: Cannot Reproduce > Master hangs if shutdown requested while in state "HAS_LOCK" > > > Key: ACCUMULO-4513 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4513 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.6, 1.7.2 >Reporter: John Vines >Priority: Critical > Fix For: 2.0.0 > > > The StatusThread.run() method does not have any means to change the masters > state out of HAS_LOCK when CLEAN_STOP is requested, which can cause the > master to get perpetually stuck > Additionally, because the master never hit the NORMAL state, the main > Master.run() was jammed at waitForMetadataUpgrade.await() so the thrift > server was never started and shutdown couldn't be issued directly (not > entirely confident that would have actually fixed anything though this is > contrary to the the state transition chart which says we can go from > HAVE_LOCK->STOP) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4513) Master hangs if shutdown requested while in state "HAS_LOCK"
[ https://issues.apache.org/jira/browse/ACCUMULO-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4513: - Fix Version/s: (was: 2.0.0) > Master hangs if shutdown requested while in state "HAS_LOCK" > > > Key: ACCUMULO-4513 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4513 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.6, 1.7.2 >Reporter: John Vines >Priority: Critical > > The StatusThread.run() method does not have any means to change the masters > state out of HAS_LOCK when CLEAN_STOP is requested, which can cause the > master to get perpetually stuck > Additionally, because the master never hit the NORMAL state, the main > Master.run() was jammed at waitForMetadataUpgrade.await() so the thrift > server was never started and shutdown couldn't be issued directly (not > entirely confident that would have actually fixed anything though this is > contrary to the the state transition chart which says we can go from > HAVE_LOCK->STOP) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4513) Master hangs if shutdown requested while in state "HAS_LOCK"
[ https://issues.apache.org/jira/browse/ACCUMULO-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820411#comment-16820411 ] Michael Miller commented on ACCUMULO-4513: -- [~vines] Are you still seeing this problem in 1.8 or 1.9? > Master hangs if shutdown requested while in state "HAS_LOCK" > > > Key: ACCUMULO-4513 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4513 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.6.6, 1.7.2 >Reporter: John Vines >Priority: Critical > Fix For: 2.0.0 > > > The StatusThread.run() method does not have any means to change the masters > state out of HAS_LOCK when CLEAN_STOP is requested, which can cause the > master to get perpetually stuck > Additionally, because the master never hit the NORMAL state, the main > Master.run() was jammed at waitForMetadataUpgrade.await() so the thrift > server was never started and shutdown couldn't be issued directly (not > entirely confident that would have actually fixed anything though this is > contrary to the the state transition chart which says we can go from > HAVE_LOCK->STOP) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-3888) getActiveScans should not eat TableNotFoundException
[
https://issues.apache.org/jira/browse/ACCUMULO-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820409#comment-16820409
]
Michael Miller commented on ACCUMULO-3888:
--
[~elserj] are you still seeing this exception in 1.8 or 1.9?
> getActiveScans should not eat TableNotFoundException
>
>
> Key: ACCUMULO-3888
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3888
> Project: Accumulo
> Issue Type: Bug
> Components: client
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.0
>
>
> Noticed this awkwardness during integration tests running against a real
> cluster.
> {noformat}
> org.apache.accumulo.core.client.TableNotFoundException: Table (Id=r) does not
> exist
> at org.apache.accumulo.core.client.impl.Tables.getTableName(Tables.java:128)
> at
> org.apache.accumulo.core.client.impl.ActiveScanImpl.(ActiveScanImpl.java:63)
> at
> org.apache.accumulo.core.client.impl.InstanceOperationsImpl.getActiveScans(InstanceOperationsImpl.java:138)
> at org.apache.accumulo.test.functional.ScanIdIT.testScanId(ScanIdIT.java:151)
> {noformat}
> The table from the previous test was deleted at the end of the test, but,
> somehow, a tabletserver returned an ActiveScan for that table. When the
> client tried to unwrap the table ID into a table name, it got a
> TableNotFoundException.
> Semantically, if a client is asking for active scans on a server, and the
> server reports a scan for a table the client doesn't think exists, it's
> reasonable to assume it was just deleted and not return that ActiveScan from
> the API call.
> Right now, this situation results in an exception back to the client and they
> get no results.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-3898) `admin stop` created deadlock in TabletServer being stopped
[
https://issues.apache.org/jira/browse/ACCUMULO-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16820400#comment-16820400
]
Michael Miller commented on ACCUMULO-3898:
--
[~elserj] are you still seeing this in 1.8 or 1.9?
> `admin stop` created deadlock in TabletServer being stopped
> ---
>
> Key: ACCUMULO-3898
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3898
> Project: Accumulo
> Issue Type: Bug
> Components: tserver
>Affects Versions: 1.7.0
>Reporter: Josh Elser
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 0001-ACCUMULO-3898-Test-to-reproduce.patch
>
>
> Take a tabletserver, tserver1, one of a few.
> The other tabletservers have already been requested to stop and all have
> stopped (via {{admin stop}}).
> {noformat}
> 2015-06-10 21:07:40,485 [master.Master] DEBUG: Seeding FATE op to shutdown
> tserver1:9997[24ddf314d8c0010] with tid 9215266058859846639
> 2015-06-10 21:07:40,503 [master.EventCoordinator] INFO : Tablet Server
> shutdown requested for tserver1:9997[24ddf314d8c0010]
> {noformat}
> The master FATE op gets seeded to shutdown tserver1. As we can guess, since
> it's the last server, it's hosting {{r<<}}. It unloads it
> {noformat}
> 2015-06-10 21:07:40,581 [tablet.Tablet] DEBUG: initiateClose(saveState=true
> queueMinC=false disableWrites=false) +r<<
> 2015-06-10 21:07:40,581 [tablet.Tablet] DEBUG: completeClose(saveState=true
> completeClose=true) +r<<
> 2015-06-10 21:07:40,587 [tserver.TabletServer] DEBUG: MultiScanSess
> master:58287 1 entries in 0.00 secs (lookup_time:0.00 secs tablets:1 ranges:1)
> 2015-06-10 21:07:40,608 [tserver.NativeMap] DEBUG: Deallocating native map
> 0x04df6fa0
> 2015-06-10 21:07:40,608 [tserver.NativeMap] DEBUG: Deallocating native map
> 0x04df7040
> 2015-06-10 21:07:40,609 [tserver.NativeMap] DEBUG: Deallocating native map
> 0x022b4da0
> 2015-06-10 21:07:40,609 [tablet.Tablet] TABLET_HIST: +r<< closed
> 2015-06-10 21:07:40,609 [tserver.TabletServer] DEBUG: Unassigning
> +r<<@(null,tserver1:9997[24ddf314d8c0010],null)
> 2015-06-10 21:07:40,610 [state.ZooStore] DEBUG: Removing /root_tablet/location
> 2015-06-10 21:07:40,613 [state.ZooStore] DEBUG: Removing
> /root_tablet/future_location
> 2015-06-10 21:07:40,614 [state.ZooTabletStateStore] DEBUG: unassign root
> tablet location
> 2015-06-10 21:07:40,619 [tserver.TabletServer] INFO : unloaded +r<<
> {noformat}
> After this, however, we can see it tries to run a minor compaction on a user
> tablet (1<<)
> {noformat}
> 2015-06-10 21:07:40,621 [tablet.Tablet] DEBUG: initiateClose(saveState=true
> queueMinC=false disableWrites=false) !0;~<
> 2015-06-10 21:07:40,621 [tablet.Tablet] DEBUG: completeClose(saveState=true
> completeClose=true) !0;~<
> 2015-06-10 21:07:40,622 [tablet.Tablet] DEBUG: initiateClose(saveState=true
> queueMinC=false disableWrites=false) 1<<
> 2015-06-10 21:07:40,623 [tserver.NativeMap] DEBUG: Allocated native map
> 0x02e82e00
> 2015-06-10 21:07:40,624 [impl.ThriftScanner] DEBUG: Failed to locate tablet
> for table : +r row : !0;
> 2015-06-10 21:07:40,633 [tablet.MinorCompactor] DEBUG: Begin minor compaction
> hdfs://namenode:8020/apps/accumulo/data/tables/1/default_tablet/F007.rf_tmp
> 1<<
> 2015-06-10 21:07:40,759 [tablet.Compactor] DEBUG: Compaction 1<< 590 read |
> 590 written | 12,553 entries/sec | 0.047 secs
> 2015-06-10 21:07:40,767 [tablet.Tablet] DEBUG: Logs for memory compacted: 1<<
> tserver1:9997/hdfs://namenode:8020/apps/accumulo/data/wal/tserver1+9997/09dc5a75-b9a1-45e9-bd5b-118ef811e99f
> 2015-06-10 21:07:40,767 [tablet.Tablet] DEBUG: Logs to be destroyed: 1<<
> tserver1:9997/hdfs://namenode:8020/apps/accumulo/data/wal/tserver1+9997/09dc5a75-b9a1-45e9-bd5b-118ef811e99f
> 2015-06-10 21:07:40,777 [tabletserver.LargestFirstMemoryManager] DEBUG:
> BEFORE compactionThreshold = 0.550 maxObserved = 150,256
> 2015-06-10 21:07:40,777 [tabletserver.LargestFirstMemoryManager] DEBUG: AFTER
> compactionThreshold = 0.605
> {noformat}
> So, as we might expect, this is never going to finish. The close won't happen
> because root isn't assigned, and the master isn't going to reassign root
> unless it gets a new tserver (which it won't because we're trying to stop the
> entire instance).
> To verify this is what's gumming up the works:
> {noformat}
> "tablet migration 1" daemon prio=10 tid=0x02e84800 nid=0x671 waiting
> on condition [0x7fb80a03a000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.accumulo.core.util.UtilWaitThread.sleep(UtilWaitThread.java:27)
> at
> org.apache.accumulo.core.client.impl.RootTabletLocator.locateTablet(RootTabletLocator.java:129)
> at
>
[jira] [Resolved] (ACCUMULO-4703) Attempt to pull all dependencies to latest version
[ https://issues.apache.org/jira/browse/ACCUMULO-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4703. -- Resolution: Fixed Fixed but never ending so will open on GitHub as needed. > Attempt to pull all dependencies to latest version > -- > > Key: ACCUMULO-4703 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4703 > Project: Accumulo > Issue Type: Task >Reporter: Keith Turner >Priority: Blocker > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 3h 50m > Remaining Estimate: 0h > > This is issue is motivated by discussion in ACCUMULO-4701. For 2.0.0 we > should attempt to use the latest version of any direct dependencies. Not > doing so may force user to use older versions of dependencies with bugs and > security problems. > ACCUMULO-4701 provides an example of this where Accumulo using methods that > exist in an older version of Guava but are dropped in a new version prevent a > user from using newer Guava. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-3944) Tablet attempts to split or major compact after every bulk file import
[
https://issues.apache.org/jira/browse/ACCUMULO-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller resolved ACCUMULO-3944.
--
Resolution: Won't Fix
> Tablet attempts to split or major compact after every bulk file import
> --
>
> Key: ACCUMULO-3944
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3944
> Project: Accumulo
> Issue Type: Improvement
> Components: tserver
>Reporter: Eric Newton
>Priority: Blocker
> Fix For: 2.0.0
>
>
> I noticed this bit of code in tablet, after it has bulk imported a file, but
> before the bulk import is finished:
> {code}
> if (needsSplit()) {
> getTabletServer().executeSplit(this);
> } else {
> initiateMajorCompaction(MajorCompactionReason.NORMAL);
> }
> {code}
> I'm pretty sure we can leave this to the normal tablet server mechanism for
> deciding when to split or compact.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-3944) Tablet attempts to split or major compact after every bulk file import
[
https://issues.apache.org/jira/browse/ACCUMULO-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16818055#comment-16818055
]
Michael Miller commented on ACCUMULO-3944:
--
Addressed in [https://github.com/apache/accumulo/pull/1089]
> Tablet attempts to split or major compact after every bulk file import
> --
>
> Key: ACCUMULO-3944
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3944
> Project: Accumulo
> Issue Type: Improvement
> Components: tserver
>Reporter: Eric Newton
>Priority: Blocker
> Fix For: 2.0.0
>
>
> I noticed this bit of code in tablet, after it has bulk imported a file, but
> before the bulk import is finished:
> {code}
> if (needsSplit()) {
> getTabletServer().executeSplit(this);
> } else {
> initiateMajorCompaction(MajorCompactionReason.NORMAL);
> }
> {code}
> I'm pretty sure we can leave this to the normal tablet server mechanism for
> deciding when to split or compact.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4737) Clean up cipher algorithm configuration
[ https://issues.apache.org/jira/browse/ACCUMULO-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16652183#comment-16652183 ] Michael Miller commented on ACCUMULO-4737: -- is superceded by https://github.com/apache/accumulo/pull/560 > Clean up cipher algorithm configuration > --- > > Key: ACCUMULO-4737 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4737 > Project: Accumulo > Issue Type: Improvement >Reporter: Nick Felts >Assignee: Nick Felts >Priority: Minor > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > The two property options: > crypto.cipher.algorithm.name > crypto.cipher.suite > are not used intuitively. For example, as far as I can tell, the only place > the cipher suite's algorithm name is used is to check for NullCipher. I even > tested this using bogus strings to confirm. Instead, once the suite is found > to not indicate NullCipher, the cipher.algorithm.name replaces the algorithm > found in the cipher suite for all further uses. > Further, the suite is parsed out into padding and mode options, which only > exist to pass a few unit tests and reconstruct the cipher suite using the > other specified algorithm. > This leads to some unintuitive behavior, where someone specifying an > algorithm in the cipher suite is not necessarily using their intended > algorithm, unless both options specified the the same algorithm. > To clean this up, the algorithm specified should be renamed and used for key > generation, since some keys can be used across different algorithms > (https://docs.oracle.com/javase/8/docs/api/java/security/Key.html), and the > cipher suite can be used as stated, instead of deconstructing it to then > reconstruct it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4733) Implement configurable security provider for crypto
[ https://issues.apache.org/jira/browse/ACCUMULO-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4733. -- Resolution: Fixed is superceded by [GitHub #560|https://github.com/apache/accumulo/pull/560] > Implement configurable security provider for crypto > --- > > Key: ACCUMULO-4733 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4733 > Project: Accumulo > Issue Type: New Feature >Reporter: Nick Felts >Assignee: Nick Felts >Priority: Minor > Labels: pull-request-available, release-notes > Fix For: 2.0.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Adding the ability to configure which Java security provider to use for > crypto. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4833) Replication randomwalk test is broken/misplaced
[ https://issues.apache.org/jira/browse/ACCUMULO-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4833: - Fix Version/s: 1.9.0 > Replication randomwalk test is broken/misplaced > --- > > Key: ACCUMULO-4833 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4833 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.7.4, 1.9.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 1.9.0 > > > While trying to run the Randomwalk Concurrent test, it will consistently > error out and stop due to the Replication test. This test doesn't take in > consideration the randomwalk state and simply just waits 30s and fails if the > data is not replicated. Maybe the test could be rewritten to handle the > state of replication better or it should be moved outside of randomwalk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4848) New Connector API broke Testing repo
[ https://issues.apache.org/jira/browse/ACCUMULO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4848. -- Resolution: Fixed > New Connector API broke Testing repo > - > > Key: ACCUMULO-4848 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4848 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Testing won't compile due to recent changes with the Connector API: > ACCUMULO-4784 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4819) Fix numerous warnings introduced by Connector improvements
[ https://issues.apache.org/jira/browse/ACCUMULO-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16399483#comment-16399483 ] Michael Miller commented on ACCUMULO-4819: -- This also needs to be done with accumulo-testing and accumulo-examples. > Fix numerous warnings introduced by Connector improvements > -- > > Key: ACCUMULO-4819 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4819 > Project: Accumulo > Issue Type: Improvement > Components: client >Reporter: Christopher Tubbs >Priority: Major > Fix For: 2.0.0 > > > The changes in ACCUMULO-4784 deprecated the ClientConfiguration class, and > introduced nearly 900 warnings about continued internal use of our own > deprecated old API code. > These warnings should be cleaned up, in order to reduce the noise, so new > warnings (potential bugs) can be more easily triaged instead of lost in the > noise... and so we can start using our own code internally. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4848) New Connector API broke Testing repo
[ https://issues.apache.org/jira/browse/ACCUMULO-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4848: Assignee: Michael Miller > New Connector API broke Testing repo > - > > Key: ACCUMULO-4848 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4848 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Testing won't compile due to recent changes with the Connector API: > ACCUMULO-4784 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4848) New Connector API broke Testing repo
Michael Miller created ACCUMULO-4848: Summary: New Connector API broke Testing repo Key: ACCUMULO-4848 URL: https://issues.apache.org/jira/browse/ACCUMULO-4848 Project: Accumulo Issue Type: Bug Components: test Affects Versions: 2.0.0 Reporter: Michael Miller Fix For: 2.0.0 Testing won't compile due to recent changes with the Connector API: ACCUMULO-4784 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4833) Replication randomwalk test is broken/misplaced
[ https://issues.apache.org/jira/browse/ACCUMULO-4833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4833: Assignee: Michael Miller > Replication randomwalk test is broken/misplaced > --- > > Key: ACCUMULO-4833 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4833 > Project: Accumulo > Issue Type: Bug > Components: test >Affects Versions: 1.7.4, 1.9.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > > While trying to run the Randomwalk Concurrent test, it will consistently > error out and stop due to the Replication test. This test doesn't take in > consideration the randomwalk state and simply just waits 30s and fails if the > data is not replicated. Maybe the test could be rewritten to handle the > state of replication better or it should be moved outside of randomwalk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-302) long lists in the monitor pages could be improved with summaries
[ https://issues.apache.org/jira/browse/ACCUMULO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395434#comment-16395434 ] Michael Miller commented on ACCUMULO-302: - This SHOULD be fixed with the new monitor in 2.0 but I'm marking this Fix Version to verify it on a large system. > long lists in the monitor pages could be improved with summaries > > > Key: ACCUMULO-302 > URL: https://issues.apache.org/jira/browse/ACCUMULO-302 > Project: Accumulo > Issue Type: Improvement > Components: monitor > Environment: large clusters >Reporter: Eric Newton >Priority: Critical > Fix For: 2.0.0 > > > The many lists in the monitor display can take a long time to render: we need > summaries which display averages, std dev and show the top/bottom rows > completely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-302) long lists in the monitor pages could be improved with summaries
[ https://issues.apache.org/jira/browse/ACCUMULO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-302: Fix Version/s: 2.0.0 > long lists in the monitor pages could be improved with summaries > > > Key: ACCUMULO-302 > URL: https://issues.apache.org/jira/browse/ACCUMULO-302 > Project: Accumulo > Issue Type: Improvement > Components: monitor > Environment: large clusters >Reporter: Eric Newton >Priority: Critical > Fix For: 2.0.0 > > > The many lists in the monitor display can take a long time to render: we need > summaries which display averages, std dev and show the top/bottom rows > completely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-1926) Accumulo Monitor page is sluggish on busy system
[ https://issues.apache.org/jira/browse/ACCUMULO-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-1926: Assignee: Michael Miller > Accumulo Monitor page is sluggish on busy system > > > Key: ACCUMULO-1926 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1926 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.4.4 >Reporter: Mike Drob >Assignee: Michael Miller >Priority: Minor > Fix For: 2.0.0 > > > On a large, busy cluster the monitor page can be sluggish to load. This has > been potentially traced back to the amount of data that needs to be gathered > and to the generation of the charts. > It may be possible to give the illusion of more performance (or at least a > shorter blocking wait) through some optimization techniques. Specifically, I > believe we can benefit from > http://developer.yahoo.com/performance/rules.html#flush although I do not > know how applicable this is to Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-1926) Accumulo Monitor page is sluggish on busy system
[ https://issues.apache.org/jira/browse/ACCUMULO-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395422#comment-16395422 ] Michael Miller commented on ACCUMULO-1926: -- This SHOULD be fixed with the new monitor in 2.0 but I'm marking this Fix Version to verify it on a large system. > Accumulo Monitor page is sluggish on busy system > > > Key: ACCUMULO-1926 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1926 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.4.4 >Reporter: Mike Drob >Priority: Minor > Fix For: 2.0.0 > > > On a large, busy cluster the monitor page can be sluggish to load. This has > been potentially traced back to the amount of data that needs to be gathered > and to the generation of the charts. > It may be possible to give the illusion of more performance (or at least a > shorter blocking wait) through some optimization techniques. Specifically, I > believe we can benefit from > http://developer.yahoo.com/performance/rules.html#flush although I do not > know how applicable this is to Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-1926) Accumulo Monitor page is sluggish on busy system
[ https://issues.apache.org/jira/browse/ACCUMULO-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-1926: - Fix Version/s: 2.0.0 > Accumulo Monitor page is sluggish on busy system > > > Key: ACCUMULO-1926 > URL: https://issues.apache.org/jira/browse/ACCUMULO-1926 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.4.4 >Reporter: Mike Drob >Priority: Minor > Fix For: 2.0.0 > > > On a large, busy cluster the monitor page can be sluggish to load. This has > been potentially traced back to the amount of data that needs to be gathered > and to the generation of the charts. > It may be possible to give the illusion of more performance (or at least a > shorter blocking wait) through some optimization techniques. Specifically, I > believe we can benefit from > http://developer.yahoo.com/performance/rules.html#flush although I do not > know how applicable this is to Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4835) Client should throw TableNotFoundException
[ https://issues.apache.org/jira/browse/ACCUMULO-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4835. -- Resolution: Fixed > Client should throw TableNotFoundException > -- > > Key: ACCUMULO-4835 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4835 > Project: Accumulo > Issue Type: Bug > Components: client >Affects Versions: 1.7.4, 1.9.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Labels: pull-request-available > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I saw this misleading exception throw while running randomwalk during the > concurrent OfflineTable node: > Caused by: org.apache.accumulo.core.client.AccumuloException: Unexpected > table state g0 DELETING != ONLINE > at > org.apache.accumulo.core.client.impl.TableOperationsImpl.waitForTableStateTransition(TableOperationsImpl.java:1072) > at > org.apache.accumulo.core.client.impl.TableOperationsImpl.online(TableOperationsImpl.java:1240) > at > org.apache.accumulo.test.randomwalk.concurrent.OfflineTable.visit(OfflineTable.java:47) > The table was in the process of being deleted so a TableNotFoundException > would be more helpful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4835) Client should throw TableNotFoundException
[ https://issues.apache.org/jira/browse/ACCUMULO-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4835: - Fix Version/s: 2.0.0 1.9.0 1.7.4 > Client should throw TableNotFoundException > -- > > Key: ACCUMULO-4835 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4835 > Project: Accumulo > Issue Type: Bug > Components: client >Affects Versions: 1.7.4, 1.9.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Labels: pull-request-available > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > I saw this misleading exception throw while running randomwalk during the > concurrent OfflineTable node: > Caused by: org.apache.accumulo.core.client.AccumuloException: Unexpected > table state g0 DELETING != ONLINE > at > org.apache.accumulo.core.client.impl.TableOperationsImpl.waitForTableStateTransition(TableOperationsImpl.java:1072) > at > org.apache.accumulo.core.client.impl.TableOperationsImpl.online(TableOperationsImpl.java:1240) > at > org.apache.accumulo.test.randomwalk.concurrent.OfflineTable.visit(OfflineTable.java:47) > The table was in the process of being deleted so a TableNotFoundException > would be more helpful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4835) Client should throw TableNotFoundException
[ https://issues.apache.org/jira/browse/ACCUMULO-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4835: Assignee: Michael Miller > Client should throw TableNotFoundException > -- > > Key: ACCUMULO-4835 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4835 > Project: Accumulo > Issue Type: Bug > Components: client >Affects Versions: 1.7.4, 1.9.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > > I saw this misleading exception throw while running randomwalk during the > concurrent OfflineTable node: > Caused by: org.apache.accumulo.core.client.AccumuloException: Unexpected > table state g0 DELETING != ONLINE > at > org.apache.accumulo.core.client.impl.TableOperationsImpl.waitForTableStateTransition(TableOperationsImpl.java:1072) > at > org.apache.accumulo.core.client.impl.TableOperationsImpl.online(TableOperationsImpl.java:1240) > at > org.apache.accumulo.test.randomwalk.concurrent.OfflineTable.visit(OfflineTable.java:47) > The table was in the process of being deleted so a TableNotFoundException > would be more helpful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4835) Client should throw TableNotFoundException
Michael Miller created ACCUMULO-4835: Summary: Client should throw TableNotFoundException Key: ACCUMULO-4835 URL: https://issues.apache.org/jira/browse/ACCUMULO-4835 Project: Accumulo Issue Type: Bug Components: client Affects Versions: 1.7.4, 1.9.0 Reporter: Michael Miller I saw this misleading exception throw while running randomwalk during the concurrent OfflineTable node: Caused by: org.apache.accumulo.core.client.AccumuloException: Unexpected table state g0 DELETING != ONLINE at org.apache.accumulo.core.client.impl.TableOperationsImpl.waitForTableStateTransition(TableOperationsImpl.java:1072) at org.apache.accumulo.core.client.impl.TableOperationsImpl.online(TableOperationsImpl.java:1240) at org.apache.accumulo.test.randomwalk.concurrent.OfflineTable.visit(OfflineTable.java:47) The table was in the process of being deleted so a TableNotFoundException would be more helpful. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4833) Replication randomwalk test is broken/misplaced
Michael Miller created ACCUMULO-4833: Summary: Replication randomwalk test is broken/misplaced Key: ACCUMULO-4833 URL: https://issues.apache.org/jira/browse/ACCUMULO-4833 Project: Accumulo Issue Type: Bug Components: test Affects Versions: 1.7.4, 1.9.0 Reporter: Michael Miller While trying to run the Randomwalk Concurrent test, it will consistently error out and stop due to the Replication test. This test doesn't take in consideration the randomwalk state and simply just waits 30s and fails if the data is not replicated. Maybe the test could be rewritten to handle the state of replication better or it should be moved outside of randomwalk. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4831) ExamplesIT fails with 2.0
Michael Miller created ACCUMULO-4831: Summary: ExamplesIT fails with 2.0 Key: ACCUMULO-4831 URL: https://issues.apache.org/jira/browse/ACCUMULO-4831 Project: Accumulo Issue Type: Bug Components: examples Affects Versions: 2.0.0 Reporter: Michael Miller Fix For: 2.0.0 Recent updates to make examples use Accumulo 2.0.0-SNAPSHOT now causes ExamplesIT to fail: testClasspath(org.apache.accumulo.examples.ExamplesIT) Time elapsed: 11.854 sec <<< FAILURE! java.lang.AssertionError: Level 1 classloader not present. at org.apache.accumulo.examples.ExamplesIT.testClasspath(ExamplesIT.java:212) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4820) Cleanup code for 2.0
[ https://issues.apache.org/jira/browse/ACCUMULO-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4820: Assignee: Michael Miller > Cleanup code for 2.0 > > > Key: ACCUMULO-4820 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4820 > Project: Accumulo > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 2.0.0 > > > Running IntelliJ code inspect picks up a lot of minor code clean up fixes > that we would be nice to fix sooner rather than later. > Java 5 Updates > - unnecessary boxing > - use foreach where possible > Java 7 Updates (these should definitely be fixed) > - Explicit type can be replaced with <> (aka diamond operator) > - Identical catch branches in try > - try finally replaceable with try with resources > Java 8 Updates (these would be nice, but maybe some prefer older way?) > - Replace anonymous types with lambda > - Replace code with new single Map method call > - Replace Collections.sort () with List.sort() > Other Misc performance Issues picked up by the inspector. I think these > should definitely be fixed but perhaps a sub ticket -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4820) Cleanup code for 2.0
[ https://issues.apache.org/jira/browse/ACCUMULO-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4820: - Description: Running IntelliJ code inspect picks up a lot of minor code clean up fixes that we would be nice to fix sooner rather than later. Java 5 Updates - unnecessary boxing - use foreach where possible Java 7 Updates (these should definitely be fixed) - Explicit type can be replaced with <> (aka diamond operator) - Identical catch branches in try - try finally replaceable with try with resources Java 8 Updates (these would be nice, but maybe some prefer older way?) - Replace anonymous types with lambda - Replace code with new single Map method call - Replace Collections.sort () with List.sort() Other Misc performance Issues picked up by the inspector. I think these should definitely be fixed but perhaps a sub ticket was: Running IntelliJ code inspect picks up a lot of minor code clean up fixes that we would be nice to fix sooner rather than later. Java 7 Updates (these should definitely be fixed) - Explicit type can be replaced with <> (aka diamond operator) - Identical catch branches in try - try finally replaceable with try with resources Java 8 Updates (these would be nice, but maybe some prefer older way?) - Replace anonymous types with lambda - Replace code with new single Map method call - Replace Collections.sort () with List.sort() Other Misc performance Issues picked up by the inspector. I think these should definitely be fixed but perhaps a sub ticket > Cleanup code for 2.0 > > > Key: ACCUMULO-4820 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4820 > Project: Accumulo > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Michael Miller >Priority: Minor > Fix For: 2.0.0 > > > Running IntelliJ code inspect picks up a lot of minor code clean up fixes > that we would be nice to fix sooner rather than later. > Java 5 Updates > - unnecessary boxing > - use foreach where possible > Java 7 Updates (these should definitely be fixed) > - Explicit type can be replaced with <> (aka diamond operator) > - Identical catch branches in try > - try finally replaceable with try with resources > Java 8 Updates (these would be nice, but maybe some prefer older way?) > - Replace anonymous types with lambda > - Replace code with new single Map method call > - Replace Collections.sort () with List.sort() > Other Misc performance Issues picked up by the inspector. I think these > should definitely be fixed but perhaps a sub ticket -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4820) Cleanup code for 2.0
Michael Miller created ACCUMULO-4820: Summary: Cleanup code for 2.0 Key: ACCUMULO-4820 URL: https://issues.apache.org/jira/browse/ACCUMULO-4820 Project: Accumulo Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Michael Miller Fix For: 2.0.0 Running IntelliJ code inspect picks up a lot of minor code clean up fixes that we would be nice to fix sooner rather than later. Java 7 Updates (these should definitely be fixed) - Explicit type can be replaced with <> (aka diamond operator) - Identical catch branches in try - try finally replaceable with try with resources Java 8 Updates (these would be nice, but maybe some prefer older way?) - Replace anonymous types with lambda - Replace code with new single Map method call - Replace Collections.sort () with List.sort() Other Misc performance Issues picked up by the inspector. I think these should definitely be fixed but perhaps a sub ticket -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364490#comment-16364490 ] Michael Miller commented on ACCUMULO-4806: -- Also, would it save time even if the 4 steps Keith mentioned above = total time current bulk import? Say if you can complete Steps 1 and 2 ahead of time, before data arrives? > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4702) Use of Beta or deprecated Guava methods
[ https://issues.apache.org/jira/browse/ACCUMULO-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362841#comment-16362841 ] Michael Miller commented on ACCUMULO-4702: -- I think we have done as much as we can for now. We took the modest approach of fixing Guava Beta that has been dropped, replacing simple uses and adding the plugin to detect any new Beta classes introduced in future versions. > Use of Beta or deprecated Guava methods > --- > > Key: ACCUMULO-4702 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4702 > Project: Accumulo > Issue Type: Bug >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 6h > Remaining Estimate: 0h > > Google releases Guava with beta and deprecated code that should not be used. > From Guava README: > bq. If your code is a library itself (i.e. it is used on the CLASSPATH of > users outside your own control), you should not use beta API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4702) Use of Beta or deprecated Guava methods
[ https://issues.apache.org/jira/browse/ACCUMULO-4702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4702. -- Resolution: Fixed > Use of Beta or deprecated Guava methods > --- > > Key: ACCUMULO-4702 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4702 > Project: Accumulo > Issue Type: Bug >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 6h > Remaining Estimate: 0h > > Google releases Guava with beta and deprecated code that should not be used. > From Guava README: > bq. If your code is a library itself (i.e. it is used on the CLASSPATH of > users outside your own control), you should not use beta API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4710) Replace use of Guava hash package
[
https://issues.apache.org/jira/browse/ACCUMULO-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller resolved ACCUMULO-4710.
--
Resolution: Not A Problem
> Replace use of Guava hash package
> -
>
> Key: ACCUMULO-4710
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4710
> Project: Accumulo
> Issue Type: Improvement
>Affects Versions: 1.8.1
>Reporter: Michael Miller
>Priority: Major
> Fix For: 2.0.0
>
>
> We use a few of the Guava classes from the com.google.common.hash package,
> all of which are Beta as of Guava release 23. These should be replaced with
> standard Java code to prevent future issues.
> This should definitely be fixed in 2.0 but I am not sure if it would break
> sampling in already released versions of 1.8. There shouldn't be any Guava
> Beta in 1.7.
> Here are the classes used in 2.0:
> {code}
> ./core/src/test/java/org/apache/accumulo/core/file/rfile/RFileTest.java:import
> com.google.common.hash.HashCode;
> ./core/src/test/java/org/apache/accumulo/core/file/rfile/RFileTest.java:import
> com.google.common.hash.Hasher;
> ./core/src/test/java/org/apache/accumulo/core/file/rfile/RFileTest.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/summary/Gatherer.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/client/summary/SummarizerConfiguration.java:import
> com.google.common.hash.Hasher;
> ./core/src/main/java/org/apache/accumulo/core/client/summary/SummarizerConfiguration.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/client/sample/AbstractHashSampler.java:import
> com.google.common.hash.HashFunction;
> ./core/src/main/java/org/apache/accumulo/core/client/sample/AbstractHashSampler.java:import
> com.google.common.hash.Hasher;
> ./core/src/main/java/org/apache/accumulo/core/client/sample/AbstractHashSampler.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/sample/impl/DataoutputHasher.java:import
> com.google.common.hash.Hasher;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4710) Replace use of Guava hash package
[
https://issues.apache.org/jira/browse/ACCUMULO-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362829#comment-16362829
]
Michael Miller commented on ACCUMULO-4710:
--
The Guava Beta classes need to be looked at on a class by class basis, whether
they are a risk to use or not. The classes in the hash package seem stable
enough so closing this ticket for now.
> Replace use of Guava hash package
> -
>
> Key: ACCUMULO-4710
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4710
> Project: Accumulo
> Issue Type: Improvement
>Affects Versions: 1.8.1
>Reporter: Michael Miller
>Priority: Major
> Fix For: 2.0.0
>
>
> We use a few of the Guava classes from the com.google.common.hash package,
> all of which are Beta as of Guava release 23. These should be replaced with
> standard Java code to prevent future issues.
> This should definitely be fixed in 2.0 but I am not sure if it would break
> sampling in already released versions of 1.8. There shouldn't be any Guava
> Beta in 1.7.
> Here are the classes used in 2.0:
> {code}
> ./core/src/test/java/org/apache/accumulo/core/file/rfile/RFileTest.java:import
> com.google.common.hash.HashCode;
> ./core/src/test/java/org/apache/accumulo/core/file/rfile/RFileTest.java:import
> com.google.common.hash.Hasher;
> ./core/src/test/java/org/apache/accumulo/core/file/rfile/RFileTest.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/summary/Gatherer.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/client/summary/SummarizerConfiguration.java:import
> com.google.common.hash.Hasher;
> ./core/src/main/java/org/apache/accumulo/core/client/summary/SummarizerConfiguration.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/client/sample/AbstractHashSampler.java:import
> com.google.common.hash.HashFunction;
> ./core/src/main/java/org/apache/accumulo/core/client/sample/AbstractHashSampler.java:import
> com.google.common.hash.Hasher;
> ./core/src/main/java/org/apache/accumulo/core/client/sample/AbstractHashSampler.java:import
> com.google.common.hash.Hashing;
> ./core/src/main/java/org/apache/accumulo/core/sample/impl/DataoutputHasher.java:import
> com.google.common.hash.Hasher;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4804) Bulk Ingest example is broken
[ https://issues.apache.org/jira/browse/ACCUMULO-4804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16362688#comment-16362688 ] Michael Miller commented on ACCUMULO-4804: -- Discovered this was due to examples incompatibility issues between 1.8 and 2.0. I think the easiest change would be to make examples work with Accumulo 2.0, since the 1.8 source code still has the examples built in. > Bulk Ingest example is broken > - > > Key: ACCUMULO-4804 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4804 > Project: Accumulo > Issue Type: Bug > Components: examples >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > The bulk import > ([https://github.com/milleruntime/accumulo-examples/blob/master/docs/bulkIngest.md)] > example in the new 2.0 repo does not work on its own. When trying to run > the commands, you get the error: > The following option is required: [-c | --conf] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359025#comment-16359025 ] Michael Miller commented on ACCUMULO-4806: -- Mark created one for splits as well: https://issues.apache.org/jira/browse/ACCUMULO-4808 > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4355) Provide more granular control for bulk import operations
[
https://issues.apache.org/jira/browse/ACCUMULO-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16359008#comment-16359008
]
Michael Miller commented on ACCUMULO-4355:
--
I am wondering if some of these ideas would be better realized prior to calling
Accumulo API. For example, looking at how the ingest process is calling
importDirectory() and restricting the size of directories passed to the API
could help.
> Provide more granular control for bulk import operations
>
>
> Key: ACCUMULO-4355
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4355
> Project: Accumulo
> Issue Type: Wish
> Components: master, tserver
>Reporter: Shawn Walker
>Assignee: Shawn Walker
>Priority: Major
> Fix For: 2.0.0
>
>
> Accumulo currently provides mechanisms to initiate bulk imports and to list
> bulk imports in progress. Scheduling of bulk import requests is not entirely
> deterministic, and most of the execution of a bulk-import request is done in
> a non-preemptable manner. As such, any bulk import which takes very long to
> complete can block bulk imports with higher operational priority for
> significant periods.
> To better support bulk-import-heavy applications, it would be nice if
> Accumulo would offer additional mechanisms for controlling the scheduling and
> execution of bulk imports, such as the abilities to:
> * Pause/resume bulk import in progress.
> * Prioritize/reprioritize bulk import requests.
> * Cancel bulk import in progress. If possible, cancelling a partially
> completed bulk import request should result in a rollback of changes. That
> is, a bulk import should either succeed or make no changes.
> Additionally, for multitenant situations, it would be nice if Accumulo would:
> * Provide multiple queues for bulk import requests. Each queue would have
> its requests worked serially in priority order. Requests in separate queues
> should be worked in parallel, or have time distributed among the queues in
> some manner as to make work appear roughly parallel.
>
> Implementation-wise, I'm thinking of rewriting much of the current
> bulk-loading logic. While the current logic depends upon multiple threads
> executing (potentially long-duration) blocking RPC calls, I'd like to move to
> a more event-driven/message-passing model backed by a persistent state
> machine.
> Current ideas I'm playing around with (very tentative)
> * Creating a new table {{accumulo.bulk_load_queues}} to keep track of bulk
> load progress.
> * Distributing bulk load orchestration via a mechanism similar to tablet
> assignment instead of the current blocking RPC calls (LoadFiles.java:156).
> * Implementing something akin to a two-phase commit to achieve rollback
> behavior on failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4806) Allow offline bulk imports
[ https://issues.apache.org/jira/browse/ACCUMULO-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4806: Assignee: Michael Miller > Allow offline bulk imports > -- > > Key: ACCUMULO-4806 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4806 > Project: Accumulo > Issue Type: Sub-task > Components: master, tserver >Reporter: Mark Owens >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > Allowing offline bulk imports would be useful for some customers. Currently > these customers already take tables offline to set split points but then have > to bring them back online before starting the import. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4804) Bulk Ingest example is broken
Michael Miller created ACCUMULO-4804: Summary: Bulk Ingest example is broken Key: ACCUMULO-4804 URL: https://issues.apache.org/jira/browse/ACCUMULO-4804 Project: Accumulo Issue Type: Bug Components: examples Affects Versions: 2.0.0 Reporter: Michael Miller Assignee: Michael Miller Fix For: 2.0.0 The bulk import ([https://github.com/milleruntime/accumulo-examples/blob/master/docs/bulkIngest.md)] example in the new 2.0 repo does not work on its own. When trying to run the commands, you get the error: The following option is required: [-c | --conf] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4778) Resolving table name to table id is expensive
[ https://issues.apache.org/jira/browse/ACCUMULO-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4778. -- Resolution: Fixed > Resolving table name to table id is expensive > - > > Key: ACCUMULO-4778 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4778 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Keith Turner >Assignee: Michael Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > I was running a Fluo test application and profiling the tablet server and > Fluo worker. The Fluo worker does lots small scans against Accumulo. > Resolving table names to ids (which is done for each scan) was expensive > enough to make a significant showing in the profiling data. > I looked that the 1.8 code and it does the following to resolve a table name : > * reads over all cached table ids in zookeeper putting them in a treemap > * does a lookup in the treemap > Ideally the client code would keep a cache of name to id mappings and > invalidate them when something changes in zookeeper. The data in zookeeper > is stored by id, so it does need to be inverted to lookup by name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4778) Resolving table name to table id is expensive
[ https://issues.apache.org/jira/browse/ACCUMULO-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4778: - Fix Version/s: 1.9.0 1.7.4 > Resolving table name to table id is expensive > - > > Key: ACCUMULO-4778 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4778 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Keith Turner >Assignee: Michael Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > I was running a Fluo test application and profiling the tablet server and > Fluo worker. The Fluo worker does lots small scans against Accumulo. > Resolving table names to ids (which is done for each scan) was expensive > enough to make a significant showing in the profiling data. > I looked that the 1.8 code and it does the following to resolve a table name : > * reads over all cached table ids in zookeeper putting them in a treemap > * does a lookup in the treemap > Ideally the client code would keep a cache of name to id mappings and > invalidate them when something changes in zookeeper. The data in zookeeper > is stored by id, so it does need to be inverted to lookup by name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4778) Resolving table name to table id is expensive
[ https://issues.apache.org/jira/browse/ACCUMULO-4778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4778: Assignee: Michael Miller > Resolving table name to table id is expensive > - > > Key: ACCUMULO-4778 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4778 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Keith Turner >Assignee: Michael Miller >Priority: Major > Fix For: 2.0.0 > > > I was running a Fluo test application and profiling the tablet server and > Fluo worker. The Fluo worker does lots small scans against Accumulo. > Resolving table names to ids (which is done for each scan) was expensive > enough to make a significant showing in the profiling data. > I looked that the 1.8 code and it does the following to resolve a table name : > * reads over all cached table ids in zookeeper putting them in a treemap > * does a lookup in the treemap > Ideally the client code would keep a cache of name to id mappings and > invalidate them when something changes in zookeeper. The data in zookeeper > is stored by id, so it does need to be inverted to lookup by name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4587) Update jquery version for 1.7/1.8
[ https://issues.apache.org/jira/browse/ACCUMULO-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4587. -- Resolution: Fixed > Update jquery version for 1.7/1.8 > - > > Key: ACCUMULO-4587 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4587 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.7.2, 1.8.0 >Reporter: Sean Busbey >Assignee: Michael Miller >Priority: Critical > Fix For: 1.7.4, 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > right now we bundle jquery v 1.5.1, which has been EOL for years. > we can use the [jquery migrate > plugin|http://jquery.com/download/#jquery-migrate-plugin] to help update APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4741) Remove minified versions of JS and CSS
[ https://issues.apache.org/jira/browse/ACCUMULO-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4741. -- Resolution: Fixed > Remove minified versions of JS and CSS > --- > > Key: ACCUMULO-4741 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4741 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.7.3, 1.8.1, 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Only use the full versions of external JS and CSS resources. The minified > versions shouldn't really affect the Monitor performance and just complicate > the "Open source" culture of the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4587) Update jquery version for 1.7/1.8
[ https://issues.apache.org/jira/browse/ACCUMULO-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4587: Assignee: Michael Miller > Update jquery version for 1.7/1.8 > - > > Key: ACCUMULO-4587 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4587 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.7.2, 1.8.0 >Reporter: Sean Busbey >Assignee: Michael Miller >Priority: Critical > Fix For: 1.7.4, 1.9.0 > > > right now we bundle jquery v 1.5.1, which has been EOL for years. > we can use the [jquery migrate > plugin|http://jquery.com/download/#jquery-migrate-plugin] to help update APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4741) Remove minified versions of JS and CSS
[ https://issues.apache.org/jira/browse/ACCUMULO-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4741: - Fix Version/s: 1.9.0 1.7.4 > Remove minified versions of JS and CSS > --- > > Key: ACCUMULO-4741 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4741 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.7.3, 1.8.1, 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Only use the full versions of external JS and CSS resources. The minified > versions shouldn't really affect the Monitor performance and just complicate > the "Open source" culture of the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4741) Remove minified versions of JS and CSS
[ https://issues.apache.org/jira/browse/ACCUMULO-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4741: - Affects Version/s: 1.7.3 1.8.1 > Remove minified versions of JS and CSS > --- > > Key: ACCUMULO-4741 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4741 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.7.3, 1.8.1, 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Only use the full versions of external JS and CSS resources. The minified > versions shouldn't really affect the Monitor performance and just complicate > the "Open source" culture of the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (ACCUMULO-4741) Remove minified versions of JS and CSS
[ https://issues.apache.org/jira/browse/ACCUMULO-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reopened ACCUMULO-4741: -- Re-opening to do this in 1.7 and 1.8 as well. > Remove minified versions of JS and CSS > --- > > Key: ACCUMULO-4741 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4741 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 1.7.3, 1.8.1, 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 1.7.4, 1.9.0, 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Only use the full versions of external JS and CSS resources. The minified > versions shouldn't really affect the Monitor performance and just complicate > the "Open source" culture of the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4786) XML and JSON API links not consistent
[ https://issues.apache.org/jira/browse/ACCUMULO-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4786. -- Resolution: Fixed > XML and JSON API links not consistent > -- > > Key: ACCUMULO-4786 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4786 > Project: Accumulo > Issue Type: Bug >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Links on the Monitor API should return the same info for JSON and XML -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ACCUMULO-4786) XML and JSON API links not consistent
[ https://issues.apache.org/jira/browse/ACCUMULO-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4786: - Issue Type: Bug (was: Improvement) > XML and JSON API links not consistent > -- > > Key: ACCUMULO-4786 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4786 > Project: Accumulo > Issue Type: Bug >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > > Links on the Monitor API should return the same info for JSON and XML -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4786) XML and JSON API links not consistent
Michael Miller created ACCUMULO-4786: Summary: XML and JSON API links not consistent Key: ACCUMULO-4786 URL: https://issues.apache.org/jira/browse/ACCUMULO-4786 Project: Accumulo Issue Type: Improvement Reporter: Michael Miller Links on the Monitor API should return the same info for JSON and XML -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ACCUMULO-4786) XML and JSON API links not consistent
[ https://issues.apache.org/jira/browse/ACCUMULO-4786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4786: Assignee: Michael Miller > XML and JSON API links not consistent > -- > > Key: ACCUMULO-4786 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4786 > Project: Accumulo > Issue Type: Improvement >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > > Links on the Monitor API should return the same info for JSON and XML -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4768) Monitor Look and Feel
[ https://issues.apache.org/jira/browse/ACCUMULO-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4768. -- Resolution: Invalid > Monitor Look and Feel > - > > Key: ACCUMULO-4768 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4768 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 2.0.0 > > > Catch all ticket for minor look and feel improvements for the new Monitor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4757) Update bundled jQuery for 2.0 monitor
[ https://issues.apache.org/jira/browse/ACCUMULO-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4757. -- Resolution: Fixed > Update bundled jQuery for 2.0 monitor > - > > Key: ACCUMULO-4757 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4757 > Project: Accumulo > Issue Type: Task > Components: monitor >Reporter: Christopher Tubbs >Assignee: Michael Miller >Priority: Critical > Fix For: 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > JQuery is a bit out of date. It's currently at 2.2.4, which was the last > version released in the 2.x series. Versions prior to 3.x are no longer > receiving patches, and have known bugs. > We should update to the latest versions to avoid bundling any versions which > may have known bugs. The latest version is currently 3.2.1. > (Note: I've checked flot, jquery-ui, select2, and bootstrap, and we are > currently using the latest versions of all of those right now. Along with > jQuery, that is an exhaustive list of our external monitor resources.) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4785) Monitor pages should pass W3C validation
[ https://issues.apache.org/jira/browse/ACCUMULO-4785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4785. -- Resolution: Fixed > Monitor pages should pass W3C validation > > > Key: ACCUMULO-4785 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4785 > Project: Accumulo > Issue Type: Improvement >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The final html output by the monitor should pass W3C validation: > [https://validator.w3.org/] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ACCUMULO-4785) Monitor pages should pass W3C validation
Michael Miller created ACCUMULO-4785: Summary: Monitor pages should pass W3C validation Key: ACCUMULO-4785 URL: https://issues.apache.org/jira/browse/ACCUMULO-4785 Project: Accumulo Issue Type: Improvement Reporter: Michael Miller Assignee: Michael Miller The final html output by the monitor should pass W3C validation: [https://validator.w3.org/] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ACCUMULO-4771) Replace tables in Monitor with DataTables
[ https://issues.apache.org/jira/browse/ACCUMULO-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4771. -- Resolution: Fixed > Replace tables in Monitor with DataTables > - > > Key: ACCUMULO-4771 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4771 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Major > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I found this Javascript library: https://datatables.net/ > I think this would give us everything we need to display data in the Monitor. > It would take some work to get it working but it would eliminate a lot of > custom code and give us more features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ACCUMULO-4760) NPE on server side getting replication information for monitor
[
https://issues.apache.org/jira/browse/ACCUMULO-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316621#comment-16316621
]
Michael Miller commented on ACCUMULO-4760:
--
No PR since it was pretty clear once I looked into it.
https://github.com/apache/accumulo/commit/208cfeaf57e910683cd0215ea2f5487a98dab22b
> NPE on server side getting replication information for monitor
> --
>
> Key: ACCUMULO-4760
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4760
> Project: Accumulo
> Issue Type: Bug
> Components: monitor
>Reporter: Christopher Tubbs
>Assignee: Michael Miller
> Labels: newbie
> Fix For: 2.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Without actually setting up replication, I tried looking at
> http://localhost:9995/replication in the monitor with the replication table
> both online and offline. Both seemed to have the same problem, resulting in a
> server-side HTTP 500 error on http://localhost:9995/rest/replication
> {code:java}
> 017-12-08 14:34:21,661 [servlet.ServletHandler] WARN :
> javax.servlet.ServletException: java.lang.NullPointerException
> at
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:489)
> at
> org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.accumulo.core.client.impl.Tables.getZooCache(Tables.java:52)
> at
> org.apache.accumulo.core.client.impl.Tables.getAllTables(Tables.java:238)
> at
> org.apache.accumulo.core.client.impl.Tables.getNameToIdMap(Tables.java:279)
> at
> org.apache.accumulo.monitor.rest.replication.ReplicationResource.getReplicationInformation(ReplicationResource.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
>
[jira] [Commented] (ACCUMULO-4760) NPE on server side getting replication information for monitor
[
https://issues.apache.org/jira/browse/ACCUMULO-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316543#comment-16316543
]
Michael Miller commented on ACCUMULO-4760:
--
Well I as unable to test Replication across 2 instances but the NPE is gone
since my fix. I think this issue could be closed.
> NPE on server side getting replication information for monitor
> --
>
> Key: ACCUMULO-4760
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4760
> Project: Accumulo
> Issue Type: Bug
> Components: monitor
>Reporter: Christopher Tubbs
>Assignee: Michael Miller
> Labels: newbie
> Fix For: 2.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Without actually setting up replication, I tried looking at
> http://localhost:9995/replication in the monitor with the replication table
> both online and offline. Both seemed to have the same problem, resulting in a
> server-side HTTP 500 error on http://localhost:9995/rest/replication
> {code:java}
> 017-12-08 14:34:21,661 [servlet.ServletHandler] WARN :
> javax.servlet.ServletException: java.lang.NullPointerException
> at
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:489)
> at
> org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.accumulo.core.client.impl.Tables.getZooCache(Tables.java:52)
> at
> org.apache.accumulo.core.client.impl.Tables.getAllTables(Tables.java:238)
> at
> org.apache.accumulo.core.client.impl.Tables.getNameToIdMap(Tables.java:279)
> at
> org.apache.accumulo.monitor.rest.replication.ReplicationResource.getReplicationInformation(ReplicationResource.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
>
[jira] [Commented] (ACCUMULO-4760) NPE on server side getting replication information for monitor
[
https://issues.apache.org/jira/browse/ACCUMULO-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312116#comment-16312116
]
Michael Miller commented on ACCUMULO-4760:
--
[~ctubbsii] What did you do to turn the replication table online?
> NPE on server side getting replication information for monitor
> --
>
> Key: ACCUMULO-4760
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4760
> Project: Accumulo
> Issue Type: Bug
> Components: monitor
>Reporter: Christopher Tubbs
>Assignee: Michael Miller
> Labels: newbie
> Fix For: 2.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Without actually setting up replication, I tried looking at
> http://localhost:9995/replication in the monitor with the replication table
> both online and offline. Both seemed to have the same problem, resulting in a
> server-side HTTP 500 error on http://localhost:9995/rest/replication
> {code:java}
> 017-12-08 14:34:21,661 [servlet.ServletHandler] WARN :
> javax.servlet.ServletException: java.lang.NullPointerException
> at
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:489)
> at
> org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.accumulo.core.client.impl.Tables.getZooCache(Tables.java:52)
> at
> org.apache.accumulo.core.client.impl.Tables.getAllTables(Tables.java:238)
> at
> org.apache.accumulo.core.client.impl.Tables.getNameToIdMap(Tables.java:279)
> at
> org.apache.accumulo.monitor.rest.replication.ReplicationResource.getReplicationInformation(ReplicationResource.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
>
[jira] [Commented] (ACCUMULO-4762) Synchronous JS calls are deprecated
[
https://issues.apache.org/jira/browse/ACCUMULO-4762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16305648#comment-16305648
]
Michael Miller commented on ACCUMULO-4762:
--
[~bmfach] As a heads up, I am working on ACCUMULO-4771 which should eliminate
some of these synchronous calls.
> Synchronous JS calls are deprecated
> ---
>
> Key: ACCUMULO-4762
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4762
> Project: Accumulo
> Issue Type: Bug
> Components: monitor
>Affects Versions: 2.0.0
>Reporter: Michael Miller
>Assignee: Benjamin F
> Fix For: 2.0.0
>
>
> All of the javascript in the Monitor sets the async flag to false before
> loading some values in the monitor. Once the values are loaded, we then set
> the flag to true.
> {code:javascript}
> $.ajaxSetup({
> async: false
> });
> //... load something
> $.ajaxSetup({
> async: true
> });
> {code}
> This currently gives a warning in Chrome since this behavior is deprecated:
> {code:javascript}
> [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated
> because of its detrimental effects to the end user's experience. For more
> help, check https://xhr.spec.whatwg.org/.
> {code}
> This may not be a problem now but upon further investigation this could be a
> problem in the future. According to the [XMLHttpRequest
> standard|https://xhr.spec.whatwg.org/#synchronous-flag]:
> "...Developers must not pass false for the async argument when current global
> object is a Window object." I look at this as using the Asynchronous JS in a
> way it was not intended to be used and we could probably do this better.
> Fixing this would require some redesign of the Monitor but it would be better
> to do this now before releasing 2.0.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4771) Replace tables in Monitor with DataTables
[ https://issues.apache.org/jira/browse/ACCUMULO-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4771: Assignee: Michael Miller > Replace tables in Monitor with DataTables > - > > Key: ACCUMULO-4771 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4771 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller > Fix For: 2.0.0 > > > I found this Javascript library: https://datatables.net/ > I think this would give us everything we need to display data in the Monitor. > It would take some work to get it working but it would eliminate a lot of > custom code and give us more features. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4765) Improve sortTable js function
[ https://issues.apache.org/jira/browse/ACCUMULO-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16299207#comment-16299207 ] Michael Miller commented on ACCUMULO-4765: -- If we went with DataTables (ACCUMULO-4771) this ticket would no longer be required. > Improve sortTable js function > - > > Key: ACCUMULO-4765 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4765 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Priority: Minor > Labels: javascript, newbie > Fix For: 2.0.0 > > > The sortTable() javascript function is used quite a lot (and has many > implementations) in the Monitor but takes the column number as a parameter. > While this is a simple solution that works well, it could break if the order > of the columns change. It would be nice to have a sortTable function that is > smarter and could automatically detect which column to sort. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4771) Replace tables in Monitor with DataTables
Michael Miller created ACCUMULO-4771: Summary: Replace tables in Monitor with DataTables Key: ACCUMULO-4771 URL: https://issues.apache.org/jira/browse/ACCUMULO-4771 Project: Accumulo Issue Type: Improvement Components: monitor Affects Versions: 2.0.0 Reporter: Michael Miller Fix For: 2.0.0 I found this Javascript library: https://datatables.net/ I think this would give us everything we need to display data in the Monitor. It would take some work to get it working but it would eliminate a lot of custom code and give us more features. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4768) Monitor Look and Feel
Michael Miller created ACCUMULO-4768: Summary: Monitor Look and Feel Key: ACCUMULO-4768 URL: https://issues.apache.org/jira/browse/ACCUMULO-4768 Project: Accumulo Issue Type: Improvement Components: monitor Affects Versions: 2.0.0 Reporter: Michael Miller Priority: Minor Fix For: 2.0.0 Catch all ticket for minor look and feel improvements for the new Monitor. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4768) Monitor Look and Feel
[ https://issues.apache.org/jira/browse/ACCUMULO-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4768: Assignee: Michael Miller > Monitor Look and Feel > - > > Key: ACCUMULO-4768 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4768 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller >Priority: Minor > Fix For: 2.0.0 > > > Catch all ticket for minor look and feel improvements for the new Monitor. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4766) Monitor Tables link reporting zeroes
[ https://issues.apache.org/jira/browse/ACCUMULO-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4766. -- Resolution: Fixed > Monitor Tables link reporting zeroes > > > Key: ACCUMULO-4766 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4766 > Project: Accumulo > Issue Type: Bug > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller > Fix For: 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The tables link in the monitor is reporting all zeroes for the stats. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4760) NPE on server side getting replication information for monitor
[
https://issues.apache.org/jira/browse/ACCUMULO-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Miller reassigned ACCUMULO-4760:
Assignee: (was: Michael Miller)
> NPE on server side getting replication information for monitor
> --
>
> Key: ACCUMULO-4760
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4760
> Project: Accumulo
> Issue Type: Bug
> Components: monitor
>Reporter: Christopher Tubbs
> Labels: newbie
> Fix For: 2.0.0
>
>
> Without actually setting up replication, I tried looking at
> http://localhost:9995/replication in the monitor with the replication table
> both online and offline. Both seemed to have the same problem, resulting in a
> server-side HTTP 500 error on http://localhost:9995/rest/replication
> {code:java}
> 017-12-08 14:34:21,661 [servlet.ServletHandler] WARN :
> javax.servlet.ServletException: java.lang.NullPointerException
> at
> org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:489)
> at
> org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
> at
> org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:333)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at
> org.apache.accumulo.core.client.impl.Tables.getZooCache(Tables.java:52)
> at
> org.apache.accumulo.core.client.impl.Tables.getAllTables(Tables.java:238)
> at
> org.apache.accumulo.core.client.impl.Tables.getNameToIdMap(Tables.java:279)
> at
> org.apache.accumulo.monitor.rest.replication.ReplicationResource.getReplicationInformation(ReplicationResource.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144)
> at
> org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161)
> at
>
[jira] [Resolved] (ACCUMULO-4764) Move static html from JS to templates
[ https://issues.apache.org/jira/browse/ACCUMULO-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller resolved ACCUMULO-4764. -- Resolution: Fixed > Move static html from JS to templates > - > > Key: ACCUMULO-4764 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4764 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The new Monitor has too much code embedded in the Javascript. A lot of it is > just static html code that should be created in the freemarker templates > before the JS is loaded. For example, all of the table column descriptions > used for tool tips are loaded into [one massive JS > Arrary|https://github.com/apache/accumulo/blob/master/server/monitor/src/main/resources/org/apache/accumulo/monitor/resources/js/global.js]. > Moving the static code to the templates will help greatly with maintenance, > specifically keeping external Javascript libraries up to date. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4765) Improve sortTable js function
[ https://issues.apache.org/jira/browse/ACCUMULO-4765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller updated ACCUMULO-4765: - Summary: Improve sortTable js function (was: Make sortTable more smart) > Improve sortTable js function > - > > Key: ACCUMULO-4765 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4765 > Project: Accumulo > Issue Type: Improvement > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Priority: Minor > Labels: newbie > Fix For: 2.0.0 > > > The sortTable() javascript function is used quite a lot (and has many > implementations) in the Monitor but takes the column number as a parameter. > While this is a simple solution that works well, it could break if the order > of the columns change. It would be nice to have a sortTable function that is > smarter and could automatically detect which column to sort. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ACCUMULO-4766) Monitor Tables link reporting zeroes
[ https://issues.apache.org/jira/browse/ACCUMULO-4766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Miller reassigned ACCUMULO-4766: Assignee: Michael Miller > Monitor Tables link reporting zeroes > > > Key: ACCUMULO-4766 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4766 > Project: Accumulo > Issue Type: Bug > Components: monitor >Affects Versions: 2.0.0 >Reporter: Michael Miller >Assignee: Michael Miller > Fix For: 2.0.0 > > > The tables link in the monitor is reporting all zeroes for the stats. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ACCUMULO-4766) Monitor Tables link reporting zeroes
Michael Miller created ACCUMULO-4766: Summary: Monitor Tables link reporting zeroes Key: ACCUMULO-4766 URL: https://issues.apache.org/jira/browse/ACCUMULO-4766 Project: Accumulo Issue Type: Bug Components: monitor Affects Versions: 2.0.0 Reporter: Michael Miller Fix For: 2.0.0 The tables link in the monitor is reporting all zeroes for the stats. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
