I just recently upgraded to Hangfire 1.5.2, and the Dashboard appears to be broken when using Hangfire with MSMQ. Clicking on the “Jobs” tab yields the following exception:
System.ApplicationException: Unable to parse PRIVATE=cfcc46cd-5782-4fa9-930a-01ec1f8bdc0a\00000012
at MQTools.MessageQueueExtensions.GetCount(MessageQueue messageQueue)
at Hangfire.SqlServer.Msmq.MsmqJobQueueMonitoringApi.GetEnqueuedAndFetchedCount(String queue)
at Hangfire.SqlServer.SqlServerMonitoringApi.Queues()
at Hangfire.Dashboard.Pages.QueuesPage.Execute()
at Hangfire.Dashboard.RazorPage.TransformText(String body)
at Hangfire.Dashboard.RazorPage.ToString()
at Hangfire.Dashboard.RazorPageDispatcher.Dispatch(RequestDispatcherContext context)
at Hangfire.Dashboard.MiddlewareExtensions.<>c__DisplayClass6.<>c__DisplayClass8.<UseHangfireDashboard>b__4(IDictionary`2 env)
at Microsoft.Owin.Mapping.MapMiddleware.<Invoke>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContextStage.<RunApp>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.<DoFinalWork>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.StageAsyncResult.End(IAsyncResult ar)
at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.EndFinalWork(IAsyncResult ar)
at System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
However, it appears that Hangfire is otherwise functioning correctly (jobs are being pulled of the queue and processed).
I’ve tried deleting and re-creating the MSMQ, to no avail.
I can also confirm this with my environment, I just upgraded to 1.5.2 and have the same issue when viewing the jobs queue in the dashboard. The path I’m passing is basically the same as it is in the documentation since I only have one default queue.
I have tried with the …UseMsmqQueues(@“FormatName:Direct=OS:queueServerName\private$\hangfire-{0}”, “queue1”, “queue2”, “queue3”) but when I try to open the Jobs tab in Hangfire dashboard then I get this error:
I have downloaded the 1.5.3 version of Hangfire source code, and run the tests. MsmqJobQueueMonitoringApiFacts.GetEnqueuedAndFetchedCount_ReturnsCorrectCounters fails for the same original parsing problem: System.ApplicationExceptionUnable to parse PRIVATE=a50790d8-7e9c-457b-b07a-fc902c5134c8\00000044
In MQTools.MessageQueueExtensions.GetCount(this MessageQueue messageQueue), I believe the correct member to parse for queue path should be messageQueue.QueueName instead of messageQueue.FormatName.
I.e.:
public static long GetCount(this MessageQueue messageQueue)
{
var matches = regex.Matches(messageQueue.QueueName);
if (matches.Count != 1)
throw new ApplicationException("Unable to parse " + messageQueue.QueueName);
...
}
I don’t have the time to work this into a pull request before going on break, but I believe that should fix it.
For me at least, this appears to happen when AD integration is installed with MSMQ. If you don’t need it, uninstalling it worked as a workaround for me
I’m getting the same error. Server functions, but the “Jobs” page returns Unknown Error on MessageQueueExtensions.GetCount().
Using 1.5.3.0.
Reading queue name from an web.config key setting and it looks like:
“FormatName:DIRECT=OS:server.abc.xyz\private$\hangfire-{0}”
I’ve also tried local notation like
““FormatName:DIRECT=OS:.\private$\hangfire-{0}””
Everyone has full control of the queue. Have removed AD integration feature.
If I run the code so that the queue is remote, I get the following stack instead:
