On Saturday, March 1, 2014 12:03:07 AM UTC-6, Jeremy Evans wrote:
>
> So this error appears to be due to the fact that it is trying to eager 
> load the tags (maybe due to the combination of eager_each and 
> tactical_eager_loading) and the id_map for the eager_loader contains 
> objects that aren't in the rows that eager loader is supposed to be 
> loading.  Alternatively, it could be caused by objects being added to the 
> rows while the eager_loader is running.
>

I can see how this may be the case.  I suppose I will have to remove the 
:tactical_eager_loading plugin until I can verify this somehow.


This might be due to tactical_eager_loading, single_table_inheritance, 
> eager_each, or some combination of those plugins, but obviously I'll need 
> to be able to reproduce it to debug it. How are you running that code in a 
> multi-threaded environment?  I don't see it starting any threads.  Are you 
> able to reproduce it just by running it?
>

No, I am not able to reproduce it in a single-threaded environment.  I am 
barely able to reproduce it in a multi-threaded environment.

I tried a variety of measures to attempt to ensure that this error stopped 
happening, including wrapping access to things like Object#tags invocations 
with Mutex locks, and also manually caching the result of tags (kludgy) in 
case the invocation of tags was invoking selects on the rows (manual caches 
get nilled out on updates, of course).  Nothing seemed to do the trick, 
though the caching seemed to decrease its frequency, of course.  (But even 
that was discouraging, since I had already activated the sequel caching 
plugin for all models -- Sequel::Model.plugin :caching, 
java.util.concurrent.ConcurrentHashMap.new.)

The code is running in a heavily multi-threaded environment accepting user 
requests from multiple remote connections, all of which then interact with 
the same routines, but shared memory is kept to a minimum.

The rest of the request handling code is a bit spaghetti, so I did not 
include it in the given example.  I had hoped that indicating that the 
provided code example was running in a multi-threaded environment would 
have been sufficient, though, it is certainly expected that such code would 
greatly complicate the trivial example provided.

 

> I see eager_each in the backtrace and not in the code, which leads me to 
> believe that the code you posted is not the code that generated the 
> backtrace you posted.
>

This is correct.  The code example is simplified.  You are right, the 
original code includes this:

    Sequel::Model.plugin :eager_each

This seems to be a remnant from a point when I was attempting to speed up 
some slowly running routines.  I updated the example.


You can try removing tactical_eager_loading and/or eager_each plugins and 
> see if the issue goes away, that would be good to know to help narrow down 
> the problem.
>

I will remove them, and see if the error continues to manifest itself at 
all.

 

> Also, just FYI, you don't need to require 'jdbc-postgres' or set 
> Sequel::Model.db manually.  Also, your tagged association (which you don't 
> appear to be using), needs to use a :key_method option, since object_id is 
> an existing ruby method.  Finally, Model#save returns self, so you don't 
> need to return self explicitly in tag and untag.
>

 Thank you, this is nice to know.  I tried to remove gem 'jdbc-postgres' 
from the example, and it still works; however when I remove it from my main 
program, it fails:

    Sequel::AdapterNotFound: LoadError: no such file to load -- 
sequel/adapters/postgresql
      adapter_class at 
/usr/java/jruby-1.7.4/lib/ruby/gems/shared/gems/sequel-4.7.0/lib/sequel/database/connecting.rb:31
        connect at 
/usr/java/jruby-1.7.4/lib/ruby/gems/shared/gems/sequel-4.7.0/lib/sequel/database/connecting.rb:59
        connect at 
/usr/java/jruby-1.7.4/lib/ruby/gems/shared/gems/sequel-4.7.0/lib/sequel/core.rb:95
Thank you for the other recommendations as well, I will attempt to 
incorporate them.  As always, you're incredibly helpful, Mr. Evans.

One last thing, I'm having trouble finding documentation on the usage of 
the :key_method option.  Do you happen to have a link?

Best regards,
-Nels

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" 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/sequel-talk.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to