Broken Links & Guess on 1.6 Release Date?
Brought to you by:
louisjacomet,
psreddy77
Menu
▾
▴
When looking at the Changelog page for Ehcache at http://ehcache.sourceforge.net/changes-report.html I noticed that the links to specific versions in the table at the top are broken. I viewed the source for the page and noticed that the anchor names seem to all start with 'a' (name="a1.6.0-beta2" for example) whereas the links reference the anchors without the 'a' (href="#1.6.0-beta2"). I don't know if that's an easy thing to fix, since I'm guessing the page is being generated, but I thought I'd point it out.
Greg, do you have a guess as to when ehcache 1.6 will be released? I'm hoping to upgrade to it from 1.5, but I was curious how the 1.6 timeline would mesh with that of the product I'm working on.
Thanks,
Matt
Matt
The broken links are a feature of Maven site:site it looks like.
I have no plans for anything other than bug fixes for ehcache-1.6.0 final should any new bugs turn up. 2-4 weeks should be enough. I just need to gain confidence that no one will find anything.
Greg
Ah, that's what I was afraid of (with regard to the broken links). Well, maybe it'll get fixed in a future version of Maven...
That's great about the timeline! That's soon enough that it'll work well for my project. I'll start using 1.6beta4 right away and let you know if I find any problems.
Thanks,
Matt
Hi Greg,
I just noticed on the news page for ehcache that 1.6 beta4 has been withdrawn due to a concurrency bug. Would you normally put a message about something like that on this forum or is there anywhere else I could subscribe in order to get important news like that?
Thanks,
Matt
Matt
This is the first time I have done it so it is a little unprecedented. It is a beta not a release. If I ever withdrew a release I would probably post it a little further.
I was a little concerned because one or twice since making the changes my complete test run did not finish.
The ConcurrentLinkedHashmap I am using from Ben Manes is actually in production use at his company. The issue I found I could only reproduce with cache sizes of less than 10 with a lot of threads. So a rare issue which may not affect anyone, but I did not see the point in having further usage of beta4.
Greg
Hi Greg,
That's fair. I'll make sure to check the site periodically, especially when I'm trying out a beta. Is this problem likely to delay the 1.6 release by a significant amount?
I'm actually using Ben's CLHM class as well. I haven't had any trouble with it yet, but the app in which it lives doesn't put very high demands on it. Although it's too bad there's a bug, I'm glad you found it now.
Thanks,
Matt
Matt
Ben was a little shaken from the news and is planning to pull CLHM from production use at his company. He is working on a version 2 over the next few months.
In terms of 1.6, my LFU store did not use CLHM. It used CHM and relied on a statistical sampling approach. That approach has been in use for a few years but using the old Map. The new version changes the backing map to CHM. I have been doing further testing on this with equivalent results to CLHM. I am now planning on implementing LRU and FIFO using that approach and will put out a beta shortly thereafter. Perhaps as early as next week.
But this will delay the final release until late May.
Greg
It's been a long time since I checked in with Ben. I should do so soon.
I was glad to see that you put out 1.6 beta5. Thanks!
--Matt
Sorry I missed the conversation. I've been utterly swamped lately and I wish I had been a little more proactive and at least posted Greg's concerns on my project page. Luckily everyone else I've talked with has only used it in SECOND_CHANCE mode, which does not show the problem. I am very much appreciative of Greg's excellent testing.
I have matured the algorithm posted on the design document to no longer require spin locks, become lock-free, and is quite a bit simpler. The general jist of that algorithm is posted on my google-group's page, though there are a few minor tweaks required to make it work. I need to update my design document to reflect that progress and finish my round of testing. Hopefully I can post it soon for a code review.
Greg's idea of using statistical analysis is pretty awesome, imho. Its quite out-of-the-box thinking and solves the hairy problem where mutations to maintain order drag down performance. This is what I liked about the SECOND_CHANCE algorithm, by making reads cheap at a small expense of optimal efficiency. So I think its a pretty nifty approach worth some further thought.
Cheers,
Ben
Hi Greg,
I was wondering if you could provide an updated ETA on your estimated release date for 1.6?
Thanks,
Andy
Andy
Should be this week.
Greg