[rabbitmq-discuss] Error code 541

Eran Sandler eran.sandler at gmail.com
Thu Sep 11 13:28:51 BST 2008


I use a virtual host and created a user that got access to the vhost and 
have "all" access to the queue.



This is some partial code of the publish part:


==================

MapMessageBuilder mapMessageBuilder = new MapMessageBuilder(ch);
mapMessageBuilder.Properties.DeliveryMode = 2;

foreach (KeyValuePair<string, object> pair in data) {
    if (pair.Value != null) {
        if (IsSupportedType(pair.Value.GetType())) {
            mapMessageBuilder.Body.Add(pair.Key, pair.Value);
        } else {
            throw new ApplicationException(string.Format("Parameter 
named \"{0}\" of type \"{1}\" is not supproted as a valid value.", 
pair.Key, pair.Value.GetType().Name));
        }
    }
}

ch.BasicPublish(ticket, string.Empty, string.Empty, 
mapMessageBuilder.GetContentHeader() as IBasicProperties, 
mapMessageBuilder.GetContentBody());


=======================


I use the MapMessageBuilder to add only simple types (strings, int, 
dates, etc - that's what the IsSupportedType checks) and publish it to a 
persistent queue.


This is what the web servers use to publish various actions to the queue.


On the other end I have a dedicated service that among other things 
accesses the queue to get the items published and perform various things 
according to the data sent.


The code there looks something like this:


===================


result = ch.BasicGet(ticket, queueName, false);
if (result != null) {
  try {
        ch.BasicAck(result.DeliveryTag, false);

        .

        . do some work

        .

  catch (Exception ex) {

       If we had a problem figure what it was, promote a counter on the 
job itself and submit it back to the queue (after X tries we will not 
resubmit it back)

  }


==================


The publish code keeps on working correctly while the BasicGet code, on 
the BasicGet call gets the 541 error.


When all of this started to happen I delete the content of the DB 
folder, recreated everything (including redefining the user, vhost and 
durable queue) and restarted the app again.


It worked for a while but kept on happening again. I have a snapshot of 
all the files but the persister is about 180MB (which seems to be its 
average size).


Now it runs for about 12 hours through the command line (not erlsrv) and 
so far it seems ok.

The memory jumps up and down reaching ~500-600mb and sometimes dropping 
back to 100mb and going straight up to 500-600mb. Currently its ~300Mb.



Eran



Ben Hood wrote:

> Eran,
>
> On Wed, Sep 10, 2008 at 2:06 PM, Eran Sandler <eran.sandler at gmail.com> wrote:
>   
>> The only thing I get is this:
>>
>> =ERROR REPORT==== 10-Sep-2008::05:17:39 ===
>> error on TCP connection <0.337.0> from 10.23.43.15:1193
>> connection_closed_abruptly
>>
>> =INFO REPORT==== 10-Sep-2008::05:17:39 ===
>> closing TCP connection <0.337.0> from 10.23.43.15:1193
>>
>> I see the connection created, accepted and then this error.
>>
>> I have a bunch of web server issuing data into the queue, they never get an
>> error.
>>
>> I have a dedicated process that reads info from the queue. It connects ones
>> and keeps on reading data (no subscription).
>>
>> That connection alone is making the problem. Since it gets an error I open a
>> new connection and model for it and it works a bit but then dies.
>>
>> The 541 error has no cause, as you can see.
>>     
>
> This is strange. 541 is a general internal error which would get
> logged to the server log under normal circumstances.
>
> Could you send a condensed version of your code that can help us
> reproduce this please?
>
> A 541 error will also cause the broker to close both the channel and
> the connection to the client.
>
>   
>> In addition to that, I have a lot of the following errors:
>>
>> =ERROR REPORT==== 10-Sep-2008::05:17:39 ===
>> Lax ticket check mode: ignoring cross-realm access for ticket 0
>>
>> Though I think they are not related.
>>     
>
> No, this is just a cosmetic bug in 1.4.0 which has been fixed in the
> mainline code and will not be there in the next release.
>
> HTH,
>
> Ben
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080911/c329c193/attachment.htm 


More information about the rabbitmq-discuss mailing list