14:10:52 <trustin> #startmeeting
14:11:02 <jbott> Meeting started Mon May 23 14:10:52 2011 UTC.  The chair is trustin. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:11:02 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:11:24 <trustin> OK.
14:11:29 <galderz> cool
14:11:44 <trustin> I again spent most of my last week to learn what the productization process is like.
14:12:05 <trustin> Talked with various production guys from SOA-P, EPP.
14:12:25 <trustin> Also with the QE folks like rhusar and prabhat
14:12:48 <trustin> I think I got enough knowledge to begin porting EDG 5 to AS7.
14:13:19 <trustin> I still don't have enough information about extending or repackaging AS 7, but I will get to know this week while porting.
14:13:35 <trustin> And then I finally resolved the REST server issue
14:14:08 <trustin> where it ignores If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since for POST, PUT, DELETE
14:14:44 <trustin> For now, it's been implemented to respond with '501 Not Implemented', but in the future, it should be implemented properly (in 5.1)
14:15:11 <trustin> Actually, it took much longer to fix my Scala IDE setup than to fix the bug itself :-)
14:15:37 <trustin> and then I worked with galderz to troubleshoot the Hot Rod InvalidResponseException
14:16:01 <trustin> mostly code review and discussion and I think we know the cause of the problem now :-)
14:16:18 <galderz> yeah, that was a tough one to crack
14:16:49 <trustin> so, this week, I'll focus on EDG 6, which is somewhat like terra incognita at the moment, but I'll get it done anyway.
14:17:07 <galderz> cool
14:17:18 <trustin> feel free to let me know if there is any bug that needs my attention
14:17:26 <galderz> i'll go now
14:17:33 <trustin> then i'll try to fix it up before CR4 is out
14:17:52 <galderz> i'm hoping to do a CR4 mid next week, around the 1st
14:18:04 <galderz> i'll send an email today or tomorrow about that
14:18:10 <trustin> cool
14:18:33 <galderz> so, on my side, last week I was finishing the move of our old hudson instance to cloudbees - that's pretty much now donw
14:18:58 <galderz> there might a few email addresses that need updating for the notifications for other than that it's working nicely
14:19:31 <galderz> we had some issues with the scala compiler and symbolic links but we got over those eventually
14:19:45 <sannegrinovero> bdw galderz I noticed yesterday that Dan doesn't have an account on our hudson - didn't bother creating it as you where moving it. will you add Dan to the new one? when he breaks the build it fails to send emails as it deosn't know his email.
14:20:11 <galderz> sannegrinovero: i'll check that
14:20:27 <galderz> apart from that i had quite a backlog of emails at the beginning of last week and it took me a while to get over that
14:21:01 <galderz> i fixed a fair few ISPN issues too and spent some time debugging that InvalidResponseException stuff with QE and trustin
14:21:29 <galderz> the end of the week i spent it looking at the testsuite and makign sure it's more stable together with dberiendei
14:22:25 <galderz> that's it for me - mmarkus, you wanna go next?
14:22:31 <mmarkus> sure
14:22:53 <mmarkus> last week I've worked on stuff for 5.0
14:23:00 <mmarkus> a fair amount of jiras
14:23:27 <mmarkus> still have some to do, hope I'll take a look at them this week
14:23:55 <mmarkus> also discussed with sannegrinovero and manik around the locking in infinispan
14:24:06 <mmarkus> this doc: http://community.jboss.org/wiki/PossibleLockingImprovements
14:24:17 <sannegrinovero> and much brainstorming :)
14:24:43 <mmarkus> seems like there are quite some opportunities to improve transactional throughput
14:25:18 <mmarkus> also very cool/effcient way of avoiding deadlocks by reordering lock acquisition based on their CH value
14:25:32 <mmarkus> this will be a short week for me
14:25:50 <mmarkus> I'm PTO on Thu/Fri
14:26:22 <mmarkus> but till then I plan to do some benchmarks for transactions
14:27:00 <galderz> mmarkus: anything more for 5.0 on your plate?
14:27:16 <galderz> those locking improvements are for post 5.0?
14:28:06 <mmarkus> galderz: yes, the hope is to have them in for 5.1
14:28:39 <sannegrinovero> sounds a bit experimental for 5.0
14:28:46 <mmarkus> galderz: re 5.0, nothing critical on my side
14:28:59 <sannegrinovero> #agreed locking improvements should target 5.1
14:29:06 <mmarkus> this one perhaps https://issues.jboss.org/browse/ISPN-1108
14:29:14 <jbossbot> jira [3ISPN-1108] Test(s) ignored by maven [10Open (Unresolved) Bug,7 Major,6 Mircea Markus] https://issues.jboss.org/browse/ISPN-1108
14:29:20 <mmarkus> but has to do with test suite
14:29:51 <galderz> sannegrinovero: i created an account for dan last week in cloudbess,
14:29:59 <galderz> i sent him an email
14:30:07 <mmarkus> that's it from my side
14:30:13 <galderz> i'll check if as person his email is right on the jenkins instance
14:30:30 <galderz> ok mmarkus
14:30:57 <galderz> sannegrinovero: anything on your side?
14:31:03 <galderz> i dunno where dan and pete are
14:31:10 <sannegrinovero> sure
14:31:37 <sannegrinovero> I'm mainly in design phases, of new Search integrations, and had many interesting talks with emmanuel about how we map collections on Infinispan
14:32:32 <sannegrinovero> this resulted on more details on the requests for the new fine-grained locking Manik is making, and much questioning on locking and isolation levels with Mircea
14:33:42 <sannegrinovero> I didn't code much on Infinispan, but helped some people getting started with it especially in the Search area. that resulted for example on the feedback about the JDBC cacheloader
14:33:55 <sannegrinovero> I also noticed that I'm again unable to run testsuites reliably
14:34:23 <galderz> sannegrinovero: what branch?
14:34:34 <sannegrinovero> actually it's reliable: it fails all the time for me. I wonder what you guys do to have it run properly?
14:34:39 <sannegrinovero> master
14:35:33 <sannegrinovero> Finally, OGM is also going to need sequences. We're currently implementing sequences on top of atomic operations, but this seems to be very tricky when performed in the scope of a transaction.
14:35:53 <galderz> sannegrinovero: not sure what properly means exactly here? u mean without test failures? or the build just fails in other way for u?
14:36:13 <sannegrinovero> galderz, test failures. It seems it's still leaking lots of threads.
14:36:46 <galderz> me and dan have been looking at failures and trying to eliminate them
14:36:52 <sannegrinovero> About sequences I'll try some more concepts, but as I already discussed with Mircea I'll likely going to push for a new interceptor and new flags to control eager/noneager lock acquisitions.
14:37:46 <sannegrinovero> galderz, yes it looks like a bit better than a month ago. It used to fail very soon, now it takes some minutes, but it never completes succesfully.
14:37:54 <galderz> sannegrinovero: you mean storing sequences in the cache and then trying to replicate when any changes happen?
14:38:17 <galderz> and you get an "unable to create thread " or similar?
14:38:44 <sannegrinovero> galderz, I need any way to generate a proper sequence of unique numbers. and yes the value should be replicated, it must stay unique even in case of failures.
14:39:08 <galderz> oh right, i thought you meant sequence as collection of something
14:39:15 <sannegrinovero> galderz, yes. it's the same problem I had in london. the limits on threads prevent the garbage collector and other threads from running
14:39:20 <galderz> you mean a cluster wide sequence generator
14:39:26 <sannegrinovero> exactly
14:39:37 <sannegrinovero> but it should also be fast :)
14:39:49 <galderz> sannegrinovero: dan was working on some fixes wrt to threads, maybe you should ping him again
14:40:03 <galderz> him and I are looking at testsuite stability this week
14:40:48 <sannegrinovero> galderz, yes I will. I think we should use custom executors / inject byteman in them, to be able to consistently pin leaks. because I'm concerned that it might not be a test leak, it might be some internal executor.
14:41:14 <sannegrinovero> otherwise, I understand it's hard to indentiy them.
14:42:05 <sannegrinovero> returning to the sequence generator: the problem is that it relies on atomic operations, and atomic operations are not reliable when running a transaction as it hides the correct state though "repeatable read" features.
14:42:16 <sannegrinovero> that's it for me :)
14:43:46 <galderz> sannegrinovero: we should name the Infinispan executors in a particular way (mayeb w/ test class name) so that they can be identitifed in a thread dump - that might help us to distinguish them better and see which ones are still left...
14:44:42 <galderz> sannegrinovero: what do you mean by hiding?
14:44:51 <sannegrinovero> galderz, yes that's one thing. we could dynamically set the executor names for each test, like we do for jgroups ports.
14:46:51 <sannegrinovero> galderz, if I have to transactions both perfoming a "putIfAbsent", the way it is now they won't write the value immediately and only acquire a lock at prepare-commit. they might both be able to see a non-existing value, and only perform the actualy put at commit time. but then the put is treated just as a put, and each transaction might assume it was it's own value to be the one and only value being written to the cache. same for al
14:46:57 <sannegrinovero> l replace and conditional remove operations.
14:48:03 <trustin> hmm
14:48:30 <trustin> perhaps continue in the mailing list or separate chat session? :-)
14:49:50 <galderz> sannegrinovero: you have eager locking to assist you here don't u? or are you saying that putIfAbsent does not work as such when it comes to prepare/commit? let's follow this on the dev list or separate chat indeed
14:50:16 <sannegrinovero> yes I was planning to write this on mailing list but galderz seems very interested :)
14:50:58 <trustin> haha
14:51:20 <trustin> all done?
14:51:28 <trustin> any issues to raise?
14:51:47 <sannegrinovero> sure. galderz, I'll continue our nice discussion on ML, or we can continue later, ok ?
14:52:41 <sannegrinovero> trustin, nothing to raise for 5.0. done for my part :)
14:52:47 <galderz> sannegrinovero: just curious but prob better send it to the ML and we can carry on there
14:54:03 <trustin> #endmeeting