gistfile1.irclog

[10:32]  <alesj> some weird stuff about key, lookup, get, ...
[10:33]  <galderz> alesj, is the key mutable?
[10:34]  <alesj> galderz: mutable in what way?
[10:34]  <alesj> once you create it, it cannot be changed
[10:34]  <galderz> alesj, well, the parameters that are used to calculate equals/hashcode… have they changed since you store it?
[10:34]  <alesj> no
[10:35]  <galderz> alesj, either a problem of your equals/hashcode, or a bug on our side… can't tell
[10:35]  <galderz> alesj, hook a debugger maybe...
[10:35]  <alesj> i did
[10:35]  <alesj> but dunno what to look for
[10:36]  <alesj> galderz: https://code.google.com/p/googleappengine/source/browse/trunk/java/src/main/com/google/appengine/api/datastore/Key.java
[10:36]  <galderz> alesj, MarshalledValue.hashCode()/MarshalledValue.equals() are the starting points
[10:36]  <alesj> this is the Key class
[10:38]  <galderz> alesj, if you have a test case, i can maybe have a look
[10:45]  * navssurtani (navssurtan@nat/redhat/x-tktcbsbefkxtifnq) has joined #infinispan
[10:46]  <rvansa> anistor: Hi, have you got some time to read my last two mails?
[10:47]  <alesj> galderz: i have a test case, in CD
[10:47]  <galderz> alesj, easy to run? or requires some google app engine installation stuff?
[10:47]  <alesj> should be easy to run
[10:48]  <alesj> but it needs to be build first ...
[10:48]  <alesj> let me try and create a simpler test
[10:48]  <galderz> alesj, building is fine…
[10:50]  * pruivo (~pruivo@redhat/jboss/pruivo) has joined #infinispan
[10:50]  * ChanServ gives voice to pruivo
[10:51]  <alesj> galderz: i have some snapshots ...
[10:51]  <alesj> which make things harder
[10:54]  <alesj> galderz: how is equality implemented?
[10:55]  <galderz> alesj, https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/marshall/core/MarshalledValue.java#L200
[10:55]  <alesj> yeah, but what does it mean? :-)
[10:55]  <alesj> you compare the serialized form?
[10:56]  <galderz> alesj, depends on the format that it's on
[10:56]  <galderz> alesj, if it's serialized form… or instance form...
[10:56]  <galderz> alesj, a lot depends if it;s been retrieved, if it's been serialized to send to another node...etc
[10:56]  <alesj> galderz: https://gist.github.com/alesj/6162865
[10:56]  <galderz> alesj, i already saw that
[10:57]  <alesj> this is a diff gist
[10:57]  <galderz> alesj, easiest is really to debug the code with a debugger
[10:57]  <galderz> alesj, first you need to figure out if the hashCode calculations match
[10:57]  <alesj>  • preferInstanceEquality = true
[10:57]  <alesj>  • thisInstance = {com.google.appengine.api.datastore.Key@11149}"Modules(1)"
[10:57]  <alesj>  • thatInstance = {com.google.appengine.api.datastore.Key@11134}"Modules(1)"
[10:57]  <alesj>  • that.instance = {com.google.appengine.api.datastore.Key@11134}"Modules(1)"
[10:58]  <galderz> alesj, that tells you barely noithing...
[10:58]  <alesj> no, it tells me exactly what I need
[10:58]  <galderz> is thisInstance.hashCode() equals to thatInstance.hashcode?
[10:58]  <alesj> it goes and comapres the instances via their equals
[10:58]  <alesj> which is wrong
[10:58]  <galderz> is thisInstance.equals() equals to thatInstance.equals?
[10:59]  <alesj> no
[10:59]  <alesj> as see the Key::equals
[10:59]  <galderz> why is that wrong?
[11:00]  <alesj> https://code.google.com/p/googleappengine/source/browse/trunk/java/src/main/com/google/appengine/api/datastore/Key.java#235
[11:00]  <alesj> instabce of Key
[11:00]  <alesj> where I have 2 diff Key classes
[11:00]  <galderz> alesj, and?
[11:00]  <alesj> as they come from 2 diff wars
[11:00]  <galderz> alesj, oh, the classloaders are different
[11:00]  <alesj> 2 diff ClassLoaders
[11:00]  <alesj> yup
[11:01]  <galderz> alesj, why do they need to be in two different classloaders?
[11:01]  <galderz> alesj, can't you have Key in a JBoss Module and get the wars to use it?
[11:02]  <alesj> galderz: no, as the users pack their own version of GAE jar
[11:02]  <alesj> can eventually be two diff versions
[11:02]  <alesj> but still compatible
[11:02]  <alesj> e.g. no signature changes, etc
[11:02]  <galderz> alesj, that's playing with fire...
[11:02]  <alesj> yeah, i know
[11:02]  <alesj> but that's how GAE apps are shipped
[11:02]  <alesj> and I need to support that
[11:04]  <alesj> galderz: can I somehow push in alternative equals check?
[11:04]  <alesj> for Key class
[11:04]  <galderz> alesj, the only way I can think this could work is if you provided a Equivalence impl for that key
[11:04]  <galderz> https://github.com/infinispan/infinispan/blob/master/commons/src/main/java/org/infinispan/commons/equivalence/Equivalence.java
[11:04]  <galderz> alesj, yes, precisely what we did for 5.3...
[11:05]  <alesj> cool
[11:05]  <galderz> alesj, the problem is that MarshalledValue is not using it yet
[11:05]  <alesj> galderz: how do I configure this?
[11:05]  <alesj> ah ...
[11:05]  <galderz> alesj, https://docs.jboss.org/author/display/ISPN/Storing+objects+%28e.g.+arrays%29+with+custom+Equivalence+functions
[11:06]  <galderz> alesj, but marshalled value support is not there yet
[11:06]  <galderz> alesj, why do you need storeAsBinary configured?
[11:06]  <alesj> galderz: as diff wars inside .ear can share data
[11:07]  <alesj> and the classes are similar to Key
[11:07]  <alesj> "same", but from diff CL
[11:07]  <rvansa> anistor: ping?
[11:07]  <galderz> alesj, i wonder whether even with a custom Equivalence function you'll be able to solve the issue...
[11:08]  * mmarkus (~Adium@redhat/jboss/mmarkus) has joined #infinispan
[11:08]  * ChanServ gives channel operator status to mmarkus
[11:08]  <galderz> alesj, cos you're gonna have to do a cast and that will give you a CCE, right?
[11:08]  <galderz> alesj, you could try something...
[11:08]  <alesj> galderz: mmarkus told me this - storeAsBinary — should help prevent CCE
[11:09]  <galderz> alesj, if you're using Infnispan 5.3+, set defensive="true" inside <storeAsBinary> element
[11:09]  <galderz> alesj, that forces the marshalled value to store, without leaving the instance version around
[11:09]  <anistor> rvansa: hi
[11:09]  <anistor> rvansa: was reading your emails
[11:10]  <anistor> rvansa: both protostream and query dsl are subject to change 
[11:10]  <anistor> rvansa: and I would like to write some unit tests for them myself
[11:11]  * tkimura has quit (Quit: Leaving)
[11:11]  <alesj> galderz: so, adding defensive as well
[11:11]  <alesj> while I still leave storeAsBinary::enebled
[11:12]  <alesj> galderz: or just defensive is ebough
[11:12]  <alesj> enough
[11:12]  <galderz> enable both
[11:12]  <alesj> as I have, both keys and values, with the same "diff CL" issue
[11:12]  <alesj> ok, will enable both
[11:16]  <rvansa> anistor: Ok, I understand... the thing is that in the past we have allocated like 2 weeks for the testing (before it was known how much the API will change) and it seems there will be more time required for rewriting all the stuff
[11:16]  <rvansa> anistor: so Martin asked me that I would participate on the changes...
[11:21]  <alesj> galderz: nope, didn't help
[11:22]  <galderz> alesj, hmmmm, thought it might....
[11:22]  <galderz> alesj, can you create a simpler test case and send it to me with instructions to run it? i'd like to debug it
[11:25]  <anistor> rvansa: right now everything is very much in flux, but the DSL I think it's pretty stable. so we can start writing functional tests against the dsl
[11:26]  <anistor> rvansa: and I will cleanup more stuff (that I already planned to change) and after that you can also help with unit testing on the internal impl. details.
[11:27]  <anistor> rvansa: but right now writing tests against the internals would not help much. I need about 1 day for protostream to cleanup, and couple more for the query, and then you can join safely :)
[11:27]  <rvansa> anistor: so, can you suggest to start rewriting test/org.infinispan.query to DSL API?
[11:28]  <rvansa> anistor: just one file or another, or would you recommend different approach?
[11:28]  <rvansa> anistor: *one test after another
[11:29]  <alesj> galderz: it should be a simple test to reproduce
[11:29]  <alesj> we just need "same" class
[11:29]  <alesj> in 2 diff CL
[11:29]  <alesj> where this class serves as a key
[11:30]  <anistor> rvansa: no. we do not throw the old query away, neither do we want convert them to the new api
[11:30]  <galderz> alesj, i get that :), i'm just asking if i can run the test you have right now… before heading down the path to replicate it separately....
[11:30]  <anistor> rvansa: the new DSL is just another way to do query. and we need new tests for it
[11:30]  <alesj> galderz: hmmm, imo it;s easier / faster to create a simpler test, then to setup the whoe stuff