Classic MSMQ Configuration problem

Thread is closed for posting
4 posts, 0 answers
  1. Fraser
    Fraser avatar
    5 posts
    Member since:
    Dec 2013

    Posted 11 Dec 2013 Link to this post

    I am attempting to move a legacy application

    FROM: 'Telerik.OpenAccess, Version=2011.1.316.10, Culture=neutral, PublicKeyToken=7ce17eeaf1d59342'

    TO:       'Telerik.OpenAccess, Version=2013.3.1014.1, Culture=neutral, PublicKeyToken=7ce17eeaf1d59342'

    The visual studio plugin has been upgraded.
    The references/assemblies for the specific ORM project have been upgraded
    The project uses "forward mapping" with the mappings defined in the app.config of the ORM project.
    The App.Config/Web.Config configuration remains as is - I have not upgrade from "Classic" to the newer ORM configuration(rlinq?)

    The application now runs and is capable of using the existing model classes.  It is using ObjectScope to get the database.

    However the project uses MSMQ for caching.
    I am seeing the following error logged by telerik through the tracewriter

    Unable to use one of the configured queues. LocalPath setting is 'CacheEvict-Q'. Original Exceptions:
    System.Messaging.MessageQueueException: Sharing violation resulted from queue being open already for exclusive receive.
       at System.Messaging.MessageQueue.MQCacheableInfo.get_ReadHandle()
       at System.Messaging.MessageQueue.StaleSafePurgeQueue()
       at System.Messaging.MessageQueue.Purge()
       at OpenAccessRuntime.MSMQClusterImpl.CheckAndCreateReceiveQueues(String path)

    Here are the web.config settings being used



    The error seems to go away if I manually delete the queue through "Computer Management->Services and Applications->Message Queuing->Private Queues"
    After deleting the queue, I do a page refresh and the ORM recreates the private queue and does not throw the exception.
    But the problem returns after an IISreset and page refresh.


  2. Fraser
    Fraser avatar
    5 posts
    Member since:
    Dec 2013

    Posted 11 Dec 2013 Link to this post

    If it helps...

    Microsoft Windows [Version 5.2.3790]

    Queue properties (within msmq console) indicate that it is a "Nontransactional queue"

    Changing the queue name via "localpath" setting doesnt fix the behaviour.
    Removing the "localpath" and allowing auto naming doesnt fix the behaviour.

  3. Fraser
    Fraser avatar
    5 posts
    Member since:
    Dec 2013

    Posted 11 Dec 2013 Link to this post

    Seems like this is similar

    In our case we had a website that accesses openaccess and use the L2cache
    That website had a virtual directory (using the same app pool) which also used openaccess and the same l2cache (as defined in the main websites web.config)
    The exception was being thrown from code running in the virtual directory (which is run second)

    I followed the steps in that post
    1. use "localname1;localname2" as the localname
    2. put a dispose Database().Dispose() int the global.asax  Application_End

    This seems to have stopped the exceptions from being logged. And I can see that both queue names get created.

    Are there any side-effects to this configuration ?  Is the main website and the virtual directory still participating in the same MSMQ or will their cache's potentially become out of sync ?

  4. Ralph Waldenmaier
    Ralph Waldenmaier avatar
    202 posts

    Posted 12 Dec 2013 Link to this post

    Hi Fraser,
    First I am glad that you found the solution to your problem. There are no side effects in using this approach. You might also find this blog post interesting with details about the configuration.

    The only thing I want to suggest is, to have at least 2 queue's specified per application because of the recycling mechanism in IIS as described in the blog post. Is this the case for your virtual directory?
    When each application gets its own two queues that can be used, there are no problems that the cache could get out of sync.

    I hope this information is helpful for you.
    Feel free to ask in case you have any other question.

    Ralph Waldenmaier
    OpenAccess ORM Q3 2013 simplifies your model operations even further providing you with greater flexibility. Check out the list of new features shipped with our latest release!
Back to Top