>>>>> "BG" == Brian Grossman <brian@SoftHome.net> writes:
BG> My big reason for wanting to do it in the first place was to avoid
BG> locking issues. Locking in mj1 is horrible.
Hmmm. Well, in Mj2, locking is implicit when you open a file. At least,
it is if you use the Mj::File and Mj::FileRepl modules (the latter is for
when you want to rewrite a file, so reading comes from one file, writing
goes to a separate one and you call either the commit or abandon methods to
finish things off). Of course, if you don't care about locking then you
can use the normal open call. And occasionally I want to enforce a
specific locking method so I just call flock, but that happens only in
mj_enqueue and mj_quruerun and not in the Majordomo library proper.
BG> Avoidance of locking issues, especially if also addressed in the mj2
BG> daemon's queueing would let mj2 scale to multiple machines.
A very interesting prospect, certainly. I'm not sure how it would work,
honestly. NFS mounting of the queue directory? Storing incoming messages
in a shared database?
Right now I'm having enough difficulty tracking down the memory leaks in
the queueing system to worry about scaling it to multiple machines.
- J<
References:
|
|
