PostgreSQL isn't really an option for me here at this point.
I've modified the lock functions to (hopefully) allow linux's flock semantics.
The code now maintains a list of inode/dev pairs. When a lock request arrives for an existing inode/dev, it
is forced to wait on a pthread_cond_t.The change does require that close and fclose be changed to two functions in the library to maintain the list. Otherwise the list will get out of sync with the locks. This may not be viable for the main code base.
I've attached my changes, I would appreciate any comments. Just a warning - I haven't tested it extensively, just enough to see that it stops the queue runner from starting a message a second time.
P. A. Bagyenda wrote:
We welcome a solution when one is found! The chickens among us would, if using Solaris, rather use the PostgreSQL-based queue storage module instead :)That brings a number of advantages:- Queue processing is faster for larger queues, since unlike the file-based storage which scans the entire queue directory tree on each run, this one only picks up messages due for processing- Message archival is built in. On Sep 04, 2008, at 00:02, Jason Pollock wrote:Jason Pollock wrote:I have noticed the same problem. With fcntl locks, the lock isn't associated with a file descriptor, it's associated with the file, so if someone opens the file, checks the lock and closes the file in the same process, the lock is released.Since it's a required lock, perhaps Solaris mandatory locking would be a better way to deal with the problem than a dict?http://sunsite.uakom.sk/sunworldonline/swol-04-1998/swol-04-insidesolaris.htmlCloser reading seems to indicate that that won't work either. Nuts. _______________________________________________ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel
Description: GNU Zip compressed data
_______________________________________________ Devel mailing list Devel@mbuni.org http://lists.mbuni.org/mailman/listinfo/devel