Getting MSMQ access denied errors with distributed L2 cache

[Nils C.]

Hi everyone,

we've been using open access orm with enabled L2 cache for quite some time. Now we tried to enable the distributed L2 cache as described here:

http://blogs.telerik.com/openaccessteam/posts/09-09-03/using-distributed-cache-with-telerik-openaccess-orm.aspx
http://www.telerik.com/help/openaccess-orm/openaccess-tasks-enable-second-level-cache-distributed.html
http://www.telerik.com/help/openaccess-orm/2nd-level-cache-cluster.html

We tried sticking to the provided snippets 100%. Our basic scenario includes 2 app-pools across which we'd like to synch the L2 cache. Additionally, we're dealing with roughly two dozen databases being accessed from the application - so each L2 cache needs to be dealt with.

Queues are created by the setup and seem to receive messages correctly but the app keeps crashing. The errors we get are all centered arount accessing the MSMQ system (access to message queueing system denied) or individual queues. The most severe seems to be: queue is already open with exclusive read access. So while messages appear to be sent, the app gets into trouble accessing the queues.

Do we have to account for the different databases by explicitly using different multicast IPs and names for the receiving queues (localPath) for each db? Anything else typically causing issues with the MSMQ-System? Or can all Databases use the same queue?

Anyone having a similar scenario up and running?

[Ralph Waldenmaier]

Hello Nils,

Here is the summary for your questions that are already answered in your support ticket.

1. Create two queues explicitly to be used by the application. Please ensure that the user specified in the application pool of your IIS has the appropriate rights to access the queue's. 

Why two queues? This is because IIS uses the overlapped recycling mechanism and since Telerik OpenAccess ORM requests exclusive access to the queues, this could cause conflicts, that you already get.
If you have 2 queues specified, which can be done by adding a semi-colon the queue names like in the following example:

"queue1;queue2;"

then we try to access the first queue specified and in case of problems we try the second one also. You can also specify more queues as needed.

2. In your global.asax file please add a call to dispose the database object. See the following example.

void Application_End(object sender, EventArgs e)
{
    //  Code that runs on application shutdown
    var ctx = ContextFactory.GetContextPerRequest();
    ctx.DisposeDatabase();
}

The reason for that is, that with this call, the queues are closed explicitly and can be accessed be a succeeding process. If this is not done, the recycle process will kill the app and the corresponding handles to the queues are not freed. You can only access the queue again, by rebooting the server.

Regarding your question having different databases and one multicast address specified. Logically this should not be a problem, but it is recommended to use a different multicast address if you have different databases in your environment. The reason is, that the queues will receive messages send by another application that do not belong to the actual application. Though the message will be read and therefore causes unnecessary operations in your application. Therefore I would recommend 1 multicast address per configured application.

Hope this helps.
Feel free to ask in case you have any other question.

Regards,
Ralph
Telerik