drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<boc_tothefuture[> GM.. continuing my questions from yesterday... Is the different between "concurrent" and "threadsafe" that globals and constants are shared in concurrent?
<boc_tothefuture[> Hmm.. concurrent also seems to share the base object for the file.
<boc_tothefuture[> In threadsafe, is there any mechanism to access shared data between threads? It seems like globals and constants are not even shared.
<boc_tothefuture[> Or is that impacted by? org.jruby.embed.sharing.variables ?
<boc_tothefuture[> So it looks like the sharing variable parameter will share variables in threadsafe mode, at least instance variables. which in this case is not what I want.
joast has quit [Read error: Connection reset by peer]
joast has joined #jruby
<boc_tothefuture[> I am seeing something I can't quite understand what is happening here.. I am putting a ruby hash as a value into a Java ConcurrentHashMap. When I access the ruby hash, its acting odd? (or maybe I have a bug). For example, I keep getting duplicate keys (which are strings). I checked and the hash is not set to compare_by_identity.
<boc_tothefuture[> But the contents end up looking like this:
<boc_tothefuture[> {"test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x2154ac20>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x691ce62>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x5a451aa0>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x32c4dd59>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x522fb9ff>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x2dfbcafc>}
<boc_tothefuture[> Am I not allowed to put a Ruby Hash into a Java Hashmap?
<headius[m]> Hey sorry not much work happening today but I am looking back
<headius[m]> That is odd
<boc_tothefuture[> maybe I just have a defect in my ruby code.
<headius[m]> So you put the hash in and get it out and it has changed?
<boc_tothefuture[> No it hasn't change.. but everytime I go through that method I get a new entry in the hash with the key of "test"
<headius[m]> I will try to reproduce that
<boc_tothefuture[> {"rule_sets"=>{"test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x2154ac20>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x691ce62>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x5a451aa0>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x32c4dd59>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x522fb9ff>, "test"=>#<OpenHAB::Core::DSL::Rule::RuleSet:0x2dfbcafc>}}
<boc_tothefuture[> The java hash looks like this:
<boc_tothefuture[> so it only contains one ruby hash..
<boc_tothefuture[> I mean.. I think I understand how Hash.new works with a block.. It should only get called if the key is missing, right?
<boc_tothefuture[> wait..
<boc_tothefuture[> no, that should work..
<headius[m]> yeah the block is called to provide for a missing key
<boc_tothefuture[> its ineffficient (creates a new hashmap each time), but gets ignored by the putIfAbsent.. I was going to use the computeIfAbsent but only after i got it work.
<headius[m]> hmm not seeing anything like this with a trivial example on JRuby master
<headius[m]> I will try with 9.2
<boc_tothefuture[> I am accessing with different threads in a JSR223 context...
<headius[m]> what does `puts "Creating new RuleSet: #{key}"` print out?
<boc_tothefuture[> hmmm
<boc_tothefuture[> its even the same object_id.
<boc_tothefuture[> how is that possible?
<boc_tothefuture[> I must be doing something silly
<headius[m]> string keys to a hash get deduplicated internally
<headius[m]> reduced memory and easier comparison
<boc_tothefuture[> yeah, but then how can I have multiple keys with the same id?
<headius[m]> oh right
<headius[m]> what us rule_set_map.class
<headius[m]> what is
<headius[m]> oh hmm
<headius[m]> Ruby Hash doesn't make a lot of thread safety guarantees in JRuby... we may change that in the future but if you are inserting into these Hash objects across threads I wonder if they are messing it up
<boc_tothefuture[> rule_set_map class Hash
<headius[m]> this would be a weird behavior I have not seen though
<boc_tothefuture[> There is a synchronized block because it happens during the evaluation phase, so threads should not be inserting at the same time.
<headius[m]> does it work as expected with one thread?
<headius[m]> oh ok
<boc_tothefuture[> Ther ehas to be something weird in my ruby code.. but I don't see it.
<headius[m]> yeah I am scratching my head here
<headius[m]> what does puts "Creating new RuleSet: #{key}" print out?
<boc_tothefuture[> Creating new RuleSet: test
<headius[m]> so it prints that multiple times?
<boc_tothefuture[> once everytime I run it.
<headius[m]> prints once but you have multiple entries?
<headius[m]> sorry just trying to clarify
<boc_tothefuture[> yep, everytime it runs I get a new entry
<headius[m]> ok so it seems like it is not inserting properly or not seeing there is already an entry
<headius[m]> for "test"
<boc_tothefuture[> yeah if I do a key? "test" it comes back false.
<headius[m]> in your loop that prints out the keys add this
<headius[m]> puts JRuby.ref(key).getRuntime
<headius[m]> might need to require 'jruby' somewhere
<boc_tothefuture[> sorry... my window didn't notify of new message.
<headius[m]> that's the problem
<headius[m]> each call through this code is using a String class from a different JRuby runtime but inserting them into the same Hash
<headius[m]> I saw your questions about Threadsafe mode on my way out yesterday... this is basically causing this problem I think
<headius[m]> you have one global CHM that gets one Hash in it
<headius[m]> Threadsafe mode tries to isolate calls by giving each thread its own JRuby runtime
<headius[m]> but you are sharing a single CHM and a single Hash
<headius[m]> each runtime gets its own random seed for String hash so that's why it ends up being different entries
<headius[m]> maybe you can describe more about this app and we can figure out the right way to support it
<boc_tothefuture[> Ah, ok.. But even if they are different runtimes.. wouldn't the eqls method still apply?
<headius[m]> well one part of == is obj1.class == obj2.class
<headius[m]> and they won't be the same String class
<boc_tothefuture[> ahh
<boc_tothefuture[> ok
<boc_tothefuture[> Ok, I can't lay it out now.. But let me write something up and I can paste it here for your review and comment and hopefully guidance into the right model.
<headius[m]> yeah cool
<headius[m]> we should deprecate these names and make better ones because they are confusing to me too
<boc_tothefuture[> In this particular instance, if I used a java hashmap would I be OK? Because then it will compare on java String class?
<headius[m]> threadsafe would mean synchronized single runtime to me but it is really thread-local
<headius[m]> if you used a java hashmap the keys would be fine but it still would be storing objects from different e
<headius[m]> oops
<headius[m]> different runtimes, which will have unexpected behavior
<headius[m]> unless you were only ever storing Java objects in there
<headius[m]> and strings
<boc_tothefuture[> no, those are ruby objects which I am pullint out and then doing a instance_eval on.
<boc_tothefuture[> ok, let me write it out and get your feedback..
<headius[m]> ok