On Apr 28, 2006, at 10:19 AM, Brian Yennie wrote:
It is rather crud to use PHP -> socket -> MC.
The MC socket port listening method is not robust enough, and may
went deaf under some loads.
I think Pierre would disagree. I would also - it's a whole lot more
likely to handle a big load than a CGI that loads the whole engine
with every request. There's nothing crud about it, it works quite
well.
You don't have to use PHP to handle the browser POST queries. We
have pure MC CGI written to handle POST running for years without
problem.
Unless you need to MC running as daemon explicitly, I don't see
the need of PHP here.
That was the point of this thread... I think you missed the
requirements. The original poster already has a working CGI, but
wanted a daemon solution to easily solve read/write conflicts for
the stack.
Let me proposed a solution here, which works for us. We was trying to
resolve a race condition on writing on a same file (not stack) by
intensive CGI queries.
1. moved the files onto high I/O efficient RAM disk, or the shared
memory at /dev/shm
2. implement a pseudo lock and unlock method, here is how:
# When you load stack, do this:
put false into stackOpenStatus
repeat 60 # retry for 1 minute
if there is a stack myStackName then
# try to rename it
rename myStackName to (myStackName &".lock")
if the result = "" then
# manage to rename, no error, so the lock is on!
open stack (myStackName &".lock")
put true into stackOpenStatus
exit repeat
end if
end if
wait 1 second
end repeat
# remember to test the stackOpenStatus first before proceed.
# When you write stack, do this:
save stack (myStackName &".lock") # save to the lock one
rename (myStackName &".lock") to myStackName # make it available again
Hope this helps.
--
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
