Aaron Trevena (aaron.tr...@gmail.com)

I've managed to isolate the problem to only occuring after the object
has been thawed from the cache and the source refreshed, but no
further than that as the data I'm using for the relationships should
be pulled from said cache anyway.

It's very puzzling, everything works elsewhere apart from relations
from this thawed object. No time to investigate it further at the
moment I'm afraid.

A.

Hi All,

I have a peculiar problem.

I've defined a bunch of has_many relations, but when I call them an
object they use the it's own table and class...

i.e.
---
package CustomField;

...

__PACKAGE__->has_many(custom_field_values => 'CustomFieldValue', {
'foreign.custom_field_id' => 'self.custom_field_id' });
----

yet when I call custom_field_values on a CustomField object I get
CustomField objects back, and it queries the custom_field rather than
custom_field_value table.

No warnings, just the wrong query and wrong object.

I've checked the definitiions of the related classes, they are all
fine and correct, how on earth can has_many get as confused as this ?

Any idea what could be causing this ?

Cheers,

A.

Hi All,

I have a lot of objects that are fairly expensive to fetch (large
trees of records), and so I'm caching them using Cache::* (via a handy
abstraction layer that allows me to swap to libmemcached or swifty if
necessary).

So far it JustWorks(TM), I put stuff in the file cache, I get it out
later, prefetched relationships work fine - I do absolutely no
serialization or anything, Cache::* handles it all for me.

When I mentioned this on irc, there was talk of needing to get the
schema to dethaw stuff, but everything I have is already
deserialized/thawed and mostly ready to go - so how would I refresh db
connections/schema for an object after it's been deserialzed by
Cache::* ?


Anybody? Bueller?

A.

On 25/03/2008, dormando <dormando@rydia.net> wrote:
> You'll get a _lot_ of noise. I think.

joy.

> Usually perlbal's at least a little noisy about crashes. Are you not
>  logging STDERR?

It's running using --daemon andusing syslog, probably worth
redirecting stderr - I'll try that.

> Can you try 1.70? There were a number of important fixes inbetween 1.60
>  and 1.70, and would help narrow it down a lot.

Sorry, I meant 1.70 :)

A.

Hi all,

Do we have any documentation / info on perlbal debug levels beyond
reading through the code.

I have 2 webservers running perlbal with an average of 200 to 300
concurrent requests at any given time during the working day and we
keep on experiencing silent crash or failure to respond (even on mgmt
port).

This is about twice a day, I can't replicate this outside of the live
environment without a lot of work and was hoping I could incrementally
increase the debug level, but with that level of traffic on a live
site I don't want to bog it down logging (especially if there is so
much information, I can't find the problem).

So how much noise to expect from debug level of 1 vs 3 ?

Any other advice welcome.

We're running 1.60 from cpan, with patch to catch empty ip / missing
socket due to hitting ip_conntrack limits.

I'm thinking of applying the "Perlbal bug: Race condition with
web_server role in _serve_request" patch, but I'm unsure if that's
actually the problem.

A.