[rabbitmq-discuss] Rabbit crash, new persister

Fri Jun 18 17:32:35 BST 2010

Hi Matthew!

Thanks for the quick reply!

On Jun 18, 2010, at 6:01 PM, Matthew Sackman wrote:

> Hi Øyvind,
> 
> On Fri, Jun 18, 2010 at 05:41:43PM +0200, Øyvind Tjervaag wrote:
>> Having some problems with getting my new persister install stable. Running the new persister branch on Windows (compiled rabbit on OSX). Checked out latest sources maybe a bit over a week ago. When I don't stress rabbit too much it's behaving very well, but if I up my publish rate I can get it to crash after a couple of minutes. Maybe even under a minute.
> 
> This looks like a permission error. Is rabbit allowed to delete under
> c:/Documents and Settings/Administrator/Application Data/RabbitMQ/db/rabbit-mnesia ?
> It's trying to delete files in there, but getting eaccess error codes
> back which the erlang documentation suggests is "Missing permission for
> the file or one of its parents".

Ah, yes I thinks so. erl.exe is running as Administrator (local), and I've started the rabbit-server just in a console logged in as Administrator. Windows claims that this user has full access tho this folder and the ones below / above it. Would it be worth moving the whole mnesia and log folders out of the application and settings folder, give full permissions there and give it another try? Can this location be set in the config file?

> 
>> When publishing small messages (maybe a couple of KB's) a couple of times per second, everything is seemingly stable and running for days. It crashes however when the messages comes in at 5 msgs/sec and the message size is around 500KB. Just doing a basic publish followed by a tx.commit for every message. Also I've been trying to figure out how to use the Channelflow in the .Net lib. Right now I don't have any code checking for it, but what exactly do I check for? Will I get it in one of the events?
> 
> The client should handle the channel.flow automatically. In the case of
> the Java client, it looks like it just blocks the caller until the
> server allows the client to send again. I would expect the .Net client
> to behave similarly - basically, you shouldn't have to worry about it -
> the client takes care of it for you.

That's handy :) good to know I hadn't missed something basic ;)

Thanks again!

Øyvind