Re: [Zope] Re: Zope Foundation Update
--On 26. Juli 2005 22:40:18 +0200 Alexander Limi <[EMAIL PROTECTED]> wrote: They did the work on our behalf, and most excellently executed the worldwide registration of the mark. The trademarks were transferred fully to the Plone Foundation as agreed. So any idea why the WIPO database tell us a different story? -aj pgpwQ0eQtakmt.pgp Description: PGP signature ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Zope Foundation Update
(Sorry about the lateness of this post, a combination of interesting SMTP blocks + Zope mailing list policies made this message not come through the first time around, which was the 20th of July. I discovered this today while browsing the archives.) On Wed, 20 Jul 2005 01:07:25 +0200, Rob Page <[EMAIL PROTECTED]> wrote: As an aside, the ZEA has also registered the Plone logo as a trademark. It is not our business, but came as a surprise to us, that the Plone Foundation is not the owner of the Plone trademark. This is wrong. In the early days of the Foundation, we had no proper legal representation and asked ZEA to represent us while setting up the legal entity for the Foundation. Plone Foundation therefore asked ZEA to assist us with their trademark experts to register the Plone trademark worldwide. This is perfectly clear from the publicly available Plone Foundation board meeting minutes. They did the work on our behalf, and most excellently executed the worldwide registration of the mark. The trademarks were transferred fully to the Plone Foundation as agreed. As a result, Plone Foundation owns the worldwide trademark for Plone. -- Alexander Limi Vice President Plone Foundation ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Traceback Lines for Send Mail Error
Asad Habib wrote at 2005-7-25 15:19 -0400: > ... >socket.gethostname() is not >returning the full canonical name of the machine. "gethostname" is not required to return the FQDN (Fully Qualified Domain Name). This is not your problem. But "gethostbyname(gethostname())" should be able to resolve whatever "gethostname()" returns into an IP address. If you already told us the platform you are using, then I missed this information (or forgot it). If you work under *nix, you may add an entry to "/etc/hosts" that assigns an IP address to the value "gethostname()" returns. I cannot help you much when you work under some variety of Windows. But, I know, Windows knows a "hosts" file as well. Maybe, the same approach works there, too. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] How to display unicode character given its code
Itai Tavor wrote at 2005-7-26 11:20 +1000:
> ...
>Couldn't get it to work, though... not sure why: unicode('\u2013')
>returns u'\\u2013', which is useless.
I know why (now, that you report the problem).
'...' introduces a non unicode string in which "\u" is not recognized.
"\u" is only recognized in unicode strings.
They are introduced by "u'...'".
Thus, instead of "unicode('\u2013').encode('utf-8')", I should
have written "u'\u2013'.encode('utf-8')".
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Running more than one instance on windows often block each other
[Sune Brøndum Wøller]
> Thanks for the pointer. I have been debugging
> select_trigger.py, and has some more info:
>
> The problem is that the call a.accept() sometimes hangs.
> Apparently a.bind(self.address) allows us to bind to
> a port that another zope instance already is bound to.
>
> The code creates the server socket a, and the client socket w,
> and gets the client socket r by connecting w to a. Then it closes a.
> a goes out of scope when __init__ terminates, and is probably garbage
> collected at some point.
Unless you're using a very old Python, `a` is collected before the
call returns (where "the call" means the call of the function in which
`a` is a local variable). Very old Pythons had an idiotic __del__
method attached to their Windows socket wrapper, which inhibited
timely gc.
> I tried moving the code to the following standalone script, and I can
> reproduce
> the error with that. In the original code w is kept as an instance variable,
> and
> r is passed to asyncore.dispatcher.__init__ and probably kept there.
Yes, the socket bound to `r` also gets bound to `self.socket` by this call:
asyncore.dispatcher.__init__ (self, r)
> I simulate that by returning them, then the caller of socktest can keep them
> around.
>
> I try to call socktest from different processes A and B (two pythons):
> (w,r = socktest())
> The call in A gets port 1. The second call, in B, either blocks, or takes
> over port 1 (I see the second process taking over the port in a port
> scanner.)
Sorry, I can't reproduce this -- but you didn't give a test program,
just an isolated function, and I'm not sure what you did with it. I
called that function in an infinite loop, appending the return value
to a global list, with a short (< 0.1 second) sleep between
iterations, and closed the returned sockets fifty iterations after
they were created. Ran that loop in two processes. No hangs, or any
other oddities, for some minutes. It did _eventually_ hang-- and both
processes at the same time --with netstat showing more than 4000
sockets hanging around in TIME_WAIT state then. I assume I bashed
into some internal Windows socket resource limit there, which Windows
didn't handle gracefully. Attaching to the processes under the MSVC 6
debugger, they were hung inside the MS socket libraries. Repeated
this several times (everything appeared to work fine until > 4000
sockets were sitting in TIME_WAIT, and then both processes hung at
approximately the same time).
Concretely:
sofar = []
try:
while 1:
print '.',
stuff = socktest() # calling your function
sofar.append(stuff)
time.sleep(random.random()/10)
if len(sofar) == 50:
tup = sofar.pop(0)
w, r = tup
msg = str(random.randrange(100))
w.send(msg)
msg2 = r.recv(100)
assert msg == msg2, (msg, msg2)
for s in tup:
s.close()
except KeyboardInterrupt:
for tup in sofar:
for s in tup:
s.close()
Note that there's also a bit of code there to verify that the
connected sockets can communicate correctly; the `assert` never
triggered.
You haven't said which versions of Windows or Python you're using. I
was using XP Pro SP2 and Python 2.3.5. Don't know whether either
matters.
It was certainly the case when I ran it that your
> print port
statement needed to display ports less than 1 at times, meaning that the
> a.bind((host, port))
did raise an exception at times. It never printed a port number less
than 19997 for me. Did you ever see it print a port number less than
1?
> a.bind in B does not raise socket.error: (10048, 'Address already in use') as
> expected, when the server socket in A is closed, even though the port is used
> by
> the client socket r in A.
I'm not sure what that's saying, but could be it's an illusion. For example,
>>> import socket
>>> s = socket.socket()
>>> s.bind(('localhost', 1))
>>> s.listen(2)
>>> a1 = socket.socket()
>>> a2 = socket.socket()
>>> a1.connect(('localhost', 1))
>>> a2.connect(('localhost', 1))
>>> b1 = s.accept()
>>> b2 = s.accept()
>>> b1[0].getsockname()
('127.0.0.1', 1)
>>> b2[0].getsockname()
('127.0.0.1', 1)
>>>
That is, it's normal for the `r` in
> r, addr = a.accept()
to repeat port numbers across multiple `accept()` calls, and indeed to
duplicate the port number from the `bind` call. This always confused
me (from way back in my Unix days -- it's not "a Windows thing"), and
maybe it's not what you're talking about anyway.
> If I remove a.close(), and keep a around (by passing it to the caller), a.bind
> works as expected - it raises socket.error: (10048, 'Address already in use').
As above, I'm seeing `bind` raise exceptions regardless.
> But in the litterature on sockets, I read it should be okay to close the
> server
> socket and keep using the client sockets.
>
> So, is this a
[Zope] Re: Running more than one instance on windows often block each other
Tim Peters wrote:
[Sune B. Woeller]
...
I can see (with the excellent (and free) 'Process
Explorer' from sysinternals) that the python
processes always opens port 1, and connects by
that port to themselves on another port (for
instance 2550).
[Dieter Maurer]
You can find the relevant code in
"ZServer.medusa.thread.select_trigger.trigger.__init__"
In principle, the code should try all sockets between
"1" down to "19950" and fail only when none of them
could be bound to...
Thanks for the pointer. I have been debugging
select_trigger.py, and has some more info:
The problem is that the call a.accept() sometimes hangs.
Apparently a.bind(self.address) allows us to bind to
a port that another zope instance already is bound to.
The code creates the server socket a, and the client socket w,
and gets the client socket r by connecting w to a. Then it closes a.
a goes out of scope when __init__ terminates, and is probably garbage collected
at some point.
I tried moving the code to the following standalone script, and I can reproduce
the error with that. In the original code w is kept as an instance variable, and
r is passed to asyncore.dispatcher.__init__ and probably kept there. I simulate
that by returning them, then the caller of socktest can keep them around.
I try to call socktest from different processes A and B (two pythons):
(w,r = socktest())
The call in A gets port 1. The second call, in B, either blocks, or takes
over port 1 (I see the second process taking over the port in a port scanner.)
a.bind in B does not raise socket.error: (10048, 'Address already in use') as
expected, when the server socket in A is closed, even though the port is used by
the client socket r in A.
If I remove a.close(), and keep a around (by passing it to the caller), a.bind
works as expected - it raises socket.error: (10048, 'Address already in use').
But in the litterature on sockets, I read it should be okay to close the server
socket and keep using the client sockets.
So, is this a possible bug in bind() ?
I have tested the new code from Tim Peters, it apparently works, ports are given
out by windows.
But could the same problem with bind occur here, since a is closed (and garbage
collected) ? (far less chance for that since we do not specify port numbers, I
know).
I tried getting a pair of sockets with Tim's code, and then trying to bind a
third socket to the same port as a/r. And I got the same problem as above.
Sune
+
import socket, errno
class BindError(Exception):
pass
def socktest():
"""blabla
"""
address = ('127.9.9.9', 1)
a = socket.socket (socket.AF_INET, socket.SOCK_STREAM)
w = socket.socket (socket.AF_INET, socket.SOCK_STREAM)
# set TCP_NODELAY to true to avoid buffering
w.setsockopt(socket.IPPROTO_TCP, 1, 1)
# tricky: get a pair of connected sockets
host='127.0.0.1'
port=1
while 1:
print port
try:
a.bind((host, port))
break
except:
if port <= 19950:
raise BindError, 'Cannot bind trigger!'
port=port - 1
a.listen (1)
w.setblocking (0)
try:
w.connect ((host, port))
except:
pass
r, addr = a.accept()
a.close()
w.setblocking (1)
#return (a, w, r)
return (w, r)
#return w
+
Yup. ZODB has what looks like a copy/paste of this code, in
ZEO/zrpc/trigger.py. I didn't realize where it came from originally
until you pointed out the Medusa code here.
Anyway, it so happens I rewrote ZEO's copy a few weeks ago, in ZODB
3.4. The Windows part is much simpler there now. I don't know why
the original might fail in the way Sune reported, but perhaps the
rewritten version would not.
Before:
# tricky: get a pair of connected sockets
host='127.0.0.1'
port=1
while 1:
try:
self.address=(host, port)
a.bind(self.address)
break
except:
if port <= 19950:
raise BindError, 'Cannot bind trigger!'
port=port - 1
a.listen (1)
w.setblocking (0)
try:
w.connect (self.address)
except:
pass
r, addr = a.accept()
a.close()
w.setblocking (1)
self.trigger = w
After:
# Specifying port 0 tells Windows to pick a port for us.
a.bind(("127.0.0.1", 0))
connect_address = a.getsockname() # assigned (host, port) pair
a.listen(1)
w.connect(connect_address)
r, addr = a.accept() # r becomes asyncore's (self.)socket
a.close()
self.trigger = w
___
Zope maillist
RE: [Zope] cpu performance zope/zeo
We're using dual cpu (not dual core) 64bit AMD Opteron (Sun Fire V20's) based systems and are VERY impressed with their performance; our python benchmarks show dual Opteron 250 systems outperforming dual twin-core Xeon 3.6GHz with the same code. Almost everything we run is ZEO based and hosted over 2 or more boxes (7 or 8 in the case of our biggest system). We couldn't be happier with the combination of Opteron and ZEO. We benchmarked 64bit Opteron, 64Bit UltraSparc III, 32bit Xeon and 64bit Xeon for our applications. Opteron trounces them all in day to day use. Sun's dual core Opteron offerings are coming out VERY soon. So that will make the V20 a 4-way system, and the V40 an 8-way system! As a guide, our standard spec for a ZEO hosted Zope server is 2 x Opteron 250/252, 4Gb, dual Gbit NIC, dual 10krpm SCSI drives in RAID1 (the main ZEO backend server is a similar spec but utilising a big SATA array in RAID50). We've found we can host 6 or so big sites (resident seize of 250mb or more) on each node and still get excellent performance by duplicating across several nodes. We have ZEO served sessions and use Pound to load balance across the pool without any stickyness - meaning on each page access users will (potentially) go to a new box - resulting in much finer grained balancing and use of resources. Performance is *excellent*. -John John Snowdon - IT Support Specialist -==- School of Medical Education Development Faculty of Medical Sciences Computing University of Newcastle >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Srdan Zagorac >Sent: 26 July 2005 06:27 >To: zope@zope.org >Subject: [Zope] cpu performance zope/zeo > > >Hi > >I need a suggestion / advice regarding the CPU options for the best >ZOPE and ZEO performance. eg 32 vs 64 bits architecture, >single vs dual >core, hyper threading. >Is there any bechmarks already posted on the web?? > >Thanks > >-- >- >Srdan Zagorac >Software Developer / Webmaster / DB Administrator >Bioengineering Institute >University of Auckland >email: [EMAIL PROTECTED] >url: http://www.bioeng.auckland.ac.nz >ph: +64 9 373 7599 ext. 82046 >fax: +64 9 367 7157 >- > >___ >Zope maillist - Zope@zope.org >http://mail.zope.org/mailman/listinfo/zope >** No cross posts or HTML encoding! ** >(Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope-dev ) > ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
