Thanks Chris,
looks like I may have been bouncing messages. I did not see your earlier reply.
Your comments regarding file locations seem dead on. Sorry for the noise on that topic.
I'll try the naming change.
I've had to go back to 2.7.1 due an another error, below.
(Yes, I did rmpyc on all Produc
This thread's not over 'til the fat lady sings.
OK, so apologies first:
Paul Winkler's comment in this thread was nearer the mark than Tres Seavers. clienthome is not relevant to where caches are created, and of course I need zeo-client-home.
Problem is now that zeo-client-home seems not to have
On Sun, 2004-07-25 at 18:15, Dieter Maurer wrote:
> The bug Chris mentioned and fixed by my patch (the "CHANGES.txt"
> report for which Chris thought uninformative)...
The patch is appreciated though!
- C
___
Zope-Dev maillist - [EMAIL PROTECTED]
Russ Ferriday wrote at 2004-7-25 17:43 +0100:
>Well, I can understand Tim's comment about droppings. This
>configuration has made a mockery of my weekend. >:-(
>Looking on the bright side - it'll soon be Monday ;)
>
>First an interesting data point.
>
>Assume for now that I'm not naming my zeo-cli
On Sun, 2004-07-25 at 14:06, Chris McDonough wrote:
> Grrr... ok, here's the deal. zeo-client-name apparently no longer has
> any effect on.. the ZEO client name. ;-) I have no idea when this
> happened; I'm sure interested parties can spelunk the CVS logs to find
> out.
FWIW, I have entered thi
On Sun, 2004-07-25 at 12:43, Russ Ferriday wrote:
> Assume for now that I'm not naming my zeo-clients - this would
> bebegging for disaster - but all is not lost. For some arcane reason
> Ihave not yet tracked down, after running my 2 clients under load,
> Iget these...
> -rw-r--r-- 1 plone staf
Well, I can understand Tim's comment about droppings. This configuration has made a mockery of my weekend. >:-(
Looking on the bright side - it'll soon be Monday ;)
First an interesting data point.
Assume for now that I'm not naming my zeo-clients - this would be begging for disaster - but all is
On Fri, 2004-07-23 at 16:21, Tim Peters wrote:
> [Chris McDonough]
> > ...
> > self._f[current] = open(self._p[current],'w+b')
> >
> > will be likely to fail at the last line if you're using
> > nonpersistent cache files, because self._p[current] is (bogus)
> > '1-None-0' (relative b
[Chris McDonough]
> ...
> self._f[current] = open(self._p[current],'w+b')
>
> will be likely to fail at the last line if you're using
> nonpersistent cache files, because self._p[current] is (bogus)
> '1-None-0' (relative bogus filename).
Is it really *likely* to fail? It's just a
On Fri, 2004-07-23 at 13:18, Russ Ferriday wrote:
> On 23 Jul 2004, at 17:00, Chris McDonough wrote:
>
> Thanks a lot for the confirmation!
>
> A pint from me the next time I see you. And Tim!
>
> The next item is this message - I see many - and need to restart
> theinstance that's spewi
No, I think Tres nailed it, in his reply.
I'll confirm when I know more.
Thanks anyway.
--r.
On 23 Jul 2004, at 18:38, Paul Winkler wrote:
it shouldn't matter what directory as long as the filenames are
unique...
if so, I can't see immediately how to put the files elsewhere, per
Client.
You mea
On Fri, Jul 23, 2004 at 06:18:08PM +0100, Russ Ferriday wrote:
>
> On 23 Jul 2004, at 17:00, Chris McDonough wrote:
>
> >Thanks a lot for the confirmation!
>
> A pint from me the next time I see you. And Tim!
>
> The next item is this message - I see many - and need to restart the
> instance t
On 23 Jul 2004, at 17:00, Chris McDonough wrote:
Thanks a lot for the confirmation!
A pint from me the next time I see you. And Tim!
The next item is this message - I see many - and need to restart the instance that's spewing them:
2004-07-23T08:21:07 INFO(0) ZEC:1-None-1 load: bad record for o
Thanks a lot for the confirmation!
I haven't seen this problem crop up in several days myself, but that may
just be due to the fact that the ZEO cache hasn't flipped. (Tim, yes,
when it does happen, it only happens once; then the server is restarted
by my customer to get the site going again, so
Thanks Tim and Chris! - You were both dead on in so many respects.
Chris, There was a correlation with flip in the logs
Tim: looks like once a None occurs it sticks.
Source of the problem was an old cache file (1-None-1) that could not be overwritten by the current uid running Zope. (That's the
[Chris McDonough]
> ...
> I think the problem is related to ZEO client storage "cache flips".
Me too. The 3.2 ZEO cache alternates between two cache files, in the
two-element list self._f. Both elements are initialized to None, and
the index of the current file in use (0 or 1) is in self._curren
On Thu, 2004-07-22 at 18:51, Russ Ferriday wrote:
> Thanks, Chris.
> We're fronting two Zopes with Pound for load balancing. I can't
> seethere would be any connection with this error. But I mention it
> incase there's a pattern.
Well, I am too in this particular case, but I doubt the frontend mat
Thanks, Chris.
We're fronting two Zopes with Pound for load balancing. I can't see there would be any connection with this error. But I mention it in case there's a pattern.
Also, the database came from 2.7.0 and an earlier python. This looks like resource starvation to me. The servers run for an h
I have seen this as well but I haven't been able to pin it down.
On Thu, 2004-07-22 at 16:16, Russ Ferriday wrote:
> Hi all,
>
> On OSX 10.3 (Pahter), Python 2.3.4, Zope 2.7.1, I'm frequently
> seeingthis..
> 2004-07-22T14:00:24 ERROR(200) ZODB Couldn't load state
> for16ad
> Tracebac
19 matches
Mail list logo