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

Timothy Bish closed AMQ-5235.
-----------------------------
    Resolution: Won't Fix

LevelDB has been deprecated and is no longer supported.

> erroneous temp percent used
> ---------------------------
>
>                 Key: AMQ-5235
>                 URL: https://issues.apache.org/jira/browse/AMQ-5235
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: activemq-leveldb-store
>    Affects Versions: 5.9.0
>         Environment: debian (quality testing and production)
>            Reporter: anselme dewavrin
>
> Dear all,
> We have an activemq 5.9 configured with 1GB of tempUsage allowed. Just by 
> security because we only use persistent messages (about 6000 messages per 
> day). After severall days of use, the temp usage increases, and even shows 
> values that are above the total amount of the data on disk. Here it shows 45% 
> of its 1GB limit for the following files :
> find activemq-data -ls
> 76809801    4 drwxr-xr-x   5 anselme  anselme      4096 Jun 19 10:24 
> activemq-data
> 76809813    4 -rw-r--r--   1 anselme  anselme        24 Jun 16 16:13 
> activemq-data/store-version.txt
> 76809817    4 drwxr-xr-x   2 anselme  anselme      4096 Jun 16 16:13 
> activemq-data/dirty.index
> 76809811    4 -rw-r--r--   2 anselme  anselme      2437 Jun 16 12:06 
> activemq-data/dirty.index/000008.sst
> 76809820    4 -rw-r--r--   1 anselme  anselme        16 Jun 16 16:13 
> activemq-data/dirty.index/CURRENT
> 76809819   80 -rw-r--r--   1 anselme  anselme     80313 Jun 16 16:13 
> activemq-data/dirty.index/000011.sst
> 76809822    0 -rw-r--r--   1 anselme  anselme         0 Jun 16 16:13 
> activemq-data/dirty.index/LOCK
> 76809810  300 -rw-r--r--   2 anselme  anselme    305206 Jun 16 11:51 
> activemq-data/dirty.index/000005.sst
> 76809821 2048 -rw-r--r--   1 anselme  anselme   2097152 Jun 19 11:30 
> activemq-data/dirty.index/000012.log
> 76809818 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/dirty.index/MANIFEST-000010
> 76809816    0 -rw-r--r--   1 anselme  anselme         0 Jun 16 16:13 
> activemq-data/lock
> 76809815 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 19 11:30 
> activemq-data/0000000000f0faaf.log
> 76809823 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 16 11:50 
> activemq-data/0000000000385f46.log
> 76809807    4 drwxr-xr-x   2 anselme  anselme      4096 Jun 16 16:13 
> activemq-data/0000000000f0faaf.index
> 76809808  420 -rw-r--r--   1 anselme  anselme    429264 Jun 16 16:13 
> activemq-data/0000000000f0faaf.index/000009.log
> 76809811    4 -rw-r--r--   2 anselme  anselme      2437 Jun 16 12:06 
> activemq-data/0000000000f0faaf.index/000008.sst
> 76809812    4 -rw-r--r--   1 anselme  anselme       165 Jun 16 16:13 
> activemq-data/0000000000f0faaf.index/MANIFEST-000007
> 76809809    4 -rw-r--r--   1 anselme  anselme        16 Jun 16 16:13 
> activemq-data/0000000000f0faaf.index/CURRENT
> 76809810  300 -rw-r--r--   2 anselme  anselme    305206 Jun 16 11:51 
> activemq-data/0000000000f0faaf.index/000005.sst
> 76809814 102400 -rw-r--r--   1 anselme  anselme  104857600 Jun 12 21:06 
> activemq-data/0000000000000000.log
> 76809802    4 drwxr-xr-x   2 anselme  anselme      4096 Jun 16 16:13 
> activemq-data/plist.index
> 76809803    4 -rw-r--r--   1 anselme  anselme        16 Jun 16 16:13 
> activemq-data/plist.index/CURRENT
> 76809806    0 -rw-r--r--   1 anselme  anselme         0 Jun 16 16:13 
> activemq-data/plist.index/LOCK
> 76809805 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/plist.index/000003.log
> 76809804 1024 -rw-r--r--   1 anselme  anselme   1048576 Jun 16 16:13 
> activemq-data/plist.index/MANIFEST-000002
> The problem is that in our production system it once blocked producers with a 
> tempusage at 122%, even if the disk was empty.
> So we invesigated and executed the broker in a debugger, and found how the 
> usage is calculated. If it in the scala leveldb files : It is not based on 
> what  is on disk, but on what it thinks is on the disk. It multiplies the 
> size of one log by the number of logs known by a certain hashmap.
> I think the entries of  the hashmap are not removed when the log files are 
> purged.
> Could you confirm ?
> Thanks in advance 
> Anselme



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to