activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lionel Cons (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APLO-245) The LevelDB store does not seem to get cleaned/compacted
Date Wed, 22 Aug 2012 11:27:38 GMT

    [ https://issues.apache.org/jira/browse/APLO-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13439422#comment-13439422
] 

Lionel Cons commented on APLO-245:
----------------------------------

I've tried to use apollo-99-trunk-20120822.031617-91 but on startup I see:

2012-08-22 13:17:22,684 | INFO  | Starting store: leveldb store at /var/lib/apollo/data |
console | hawtdispatch-DEFAULT-2
2012-08-22 13:17:22,860 | WARN  | Using the pure java LevelDB implementation which is still
experimental.  If the JNI version is not available for your platform, please switch to the
BDB store instead. http://activemq.apache.org/apollo/documentation/user-manual.html#BDB_Store
| org.apache.activemq.apollo.broker.store.leveldb.LevelDBClient | leveldb store io write
[...]
2012-08-22 13:17:23,767 | INFO  | Opening the log file took: 750.47 ms | org.apache.activemq.apollo.broker.store.leveldb.LevelDBClient
| leveldb store io write
2012-08-22 13:17:25,981 | WARN  | DB operation failed. (entering recovery mode): com.google.common.util.concurrent.UncheckedExecutionException:
java.lang.NullPointerException | org.apache.activemq.apollo.broker.store.leveldb.LevelDBClient
| leveldb store io write

:-(
                
> The LevelDB store does not seem to get cleaned/compacted
> --------------------------------------------------------
>
>                 Key: APLO-245
>                 URL: https://issues.apache.org/jira/browse/APLO-245
>             Project: ActiveMQ Apollo
>          Issue Type: Bug
>            Reporter: Lionel Cons
>
> We use the default message store: LevelDB.
> On one broker with poor performance, we noticed a quite big store (file system wise)
while there are zero messages in the queues.
> In concrete terms, the REST API reports for the aggregated dest-metrics:
>   'queue_items' => 0,
>   'queue_size' => 0,
> While on the box itself, in the data directory, we see:
> $ du -ks .
> 434992	.
> $ find . -type f | wc -l
> 471
> So 400MB and 471 files is a lot to hold zero messages...
> FWIW, the store page in the console reports something quite different:
> disk usage: 760.689 mb
> Log Status
> Log File             | Msg Refs   | File Size 
> 0000003a0eb4031b.log | 0          | 100.000 mb
> Index recovery starts from log position: 0000003a0eb4031b
> Append position: 0000003a13bed684
> Index Status
>                                Compactions
> Level  Files Size(MB) Time(sec) Read(MB) Write(MB)
> --------------------------------------------------
>   0        0        0         0        0         2
>   1        7        9         2       12         9
>   2      108       91         0        0         0
>   3      114      227         0        0         0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message