Thanks!

I did try 1.3.174 the other day and noticed it fixed my issues!

Brian


On Tue, Oct 29, 2013 at 12:51 AM, Thomas Mueller <
[email protected]> wrote:

> Hi,
>
> By the way, those bugs have been fixed now. There is now a WriteBuffer
> that auto-increases capacity (similar to a ByteArrayOutputStream). And
> there was a bug in the LIRS cache that has been fixed.
>
> Regards,
> Thomas
>
> On Friday, October 11, 2013, Thomas Mueller wrote:
>
>> Hi,
>>
>> > DataUtils.ensureCapacity() isn't making a large enough ByteBuffer?
>>
>> Yes, or maybe the method is not called in some cases where it should.
>> Maybe it's better to wrap the ByteBuffer into a WriteBuffer that internally
>> calls ensureCapacity when required. The current mechanism might be a bit
>> more efficient, but also much more error prone.
>>
>> > CacheLongKeyLIRS
>>
>> Yes, this looks like a bug. While there are many test cases for this
>> class, what is not tested is overflow (when using a large cache size). I
>> just found the following code runs into an endless loop after about 
>> 54'458'000
>> entries. This is a really large cache, given that by default there are 16
>> segments (so it would fail with 16 times that number of entries), but it's
>> still a bug. Strange is that it doesn't always fail at the same entry, so
>> it might be a combination of a JVM bug and a bug in the cache. There might
>> be other overflow problems.
>>
>>     int size = 100 * 1024 * 1024;
>>     CacheLongKeyLIRS<Integer> test = new CacheLongKeyLIRS<Integer>(size,
>> 1, 1, 0);
>>     Integer value = 1;
>>     for (int i = 0; i < size; i++) {
>>         test.put(i, value);
>>     }
>>
>> Regards,
>> Thomas
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Oct 11, 2013 at 8:33 AM, Noel Grandin <[email protected]>wrote:
>>
>>> Hi
>>>
>>> I had a quick look at this exception that Brian reported:
>>>
>>>
>>>
>>>    Caused by: java.lang.NullPointerException
>>>             at
>>>    org.h2.mvstore.cache.**CacheLongKeyLIRS$Segment.**
>>> pruneStack(CacheLongKeyLIRS.**java:824)
>>>             at
>>>    org.h2.mvstore.cache.**CacheLongKeyLIRS$Segment.**
>>> convertOldestHotToCold(**CacheLongKeyLIRS.java:815)
>>>             at
>>>    org.h2.mvstore.cache.**CacheLongKeyLIRS$Segment.**
>>> evict(CacheLongKeyLIRS.java:**783)
>>>             at
>>>    org.h2.mvstore.cache.**CacheLongKeyLIRS$Segment.put(**
>>> CacheLongKeyLIRS.java:711)
>>>             at
>>>    org.h2.mvstore.cache.**CacheLongKeyLIRS.put(**
>>> CacheLongKeyLIRS.java:162)
>>>             at org.h2.mvstore.MVStore.**readPage(MVStore.java:1443)
>>>             at org.h2.mvstore.MVMap.readPage(**MVMap.java:759)
>>>             at org.h2.mvstore.Page.**getChildPage(Page.java:207)
>>>             at org.h2.mvstore.MVMap.**binarySearch(MVMap.java:449)
>>>             at org.h2.mvstore.MVMap.**binarySearch(MVMap.java:450)
>>>             at org.h2.mvstore.MVMap.**binarySearch(MVMap.java:450)
>>>             at org.h2.mvstore.MVMap.get(**MVMap.java:431)
>>>
>>>
>>>
>>>
>>> I suspect that this code in CacheLongKeyLIRS$Segment is the problem:
>>>         private void evict(Entry<V> newCold) {
>>>             // ensure there are not too many hot entries:
>>>             // left shift of 5 is multiplication by 32, that means if
>>> there are less
>>>             // than 1/32 (3.125%) cold entries, a new hot entry needs to
>>> become cold
>>>             while ((queueSize << 5) < mapSize) {
>>>                 convertOldestHotToCold();
>>>             }
>>>
>>> "queueSize" is an int , and if the queue gets big enough, the "<< 5"
>>> will operation will generate a zero because it will run move all of the
>>> bits outside the available 32 bits.
>>>
>>> I think the code should look like:
>>>             while ((((long)queueSize) << 5) < mapSize) {
>>>                 convertOldestHotToCold();
>>>             }
>>> or maybe
>>>             while (queueSize < (mapSize >> 5)) {
>>>                 convertOldestHotToCold();
>>>             }
>>>
>>>
>>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "H2 Database" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/h2-database/d5ewTdLDqiw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/h2-database.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups "H2 
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to