This project has moved and is read-only. For the latest updates, please go here.

Error submitting new tickets

Sep 16, 2009 at 10:20 PM

I apologize for the direct email to the developer.  I was on the issue tracker page and looking for where to submit for help and had a brain lapse by not seeing the discussion button.

I set TicketDesk up several weeks ago and it's worked every time when we tested it within the IT department.  I'm using integrated authentication and have all the tables stored on a seperate SQL server and a dedicated IIS server.  Both servers have low workload.

The day we announce the application within the company, we started getting errors submitting tickets.  Sometimes it works just fine though, but there is a long delay after clicking submit.  The ticket creates just fine, but the error message isn't exactly user friendly.  In the mean time, I've put a try/catch block on the context.SubmitChanges() in the NewTicket.aspx.cs and redirecting users back to the homepage in the catch block.  This is working as a bandaid, but we'd like it to work properly if possible.

What I find odd in the elmah error is that it has my local project folder in the error path but the error is from the IIS server and I can't find any reference to the path in the files.

Thank you for any help in advance.

The elmah error says:

System.Data.Linq.ChangeConflictException: Row not found or changed.

System.Web.HttpUnhandledException: Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.Data.Linq.ChangeConflictException: Row not found or changed.
   at System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode failureMode)
   at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
   at System.Data.Linq.DataContext.SubmitChanges()
   at TicketDesk.Engine.NotificationService.PrepareTicketEventNotificationForDelivery(TicketDataDataContext ctx, TicketEventNotification note, List`1 consolidations) in C:\Projects\TicketDesk\TicketDesk\Engine\NotificationService.cs:line 273
   at TicketDesk.Engine.NotificationService.SendTicketEventNotificationEmail(TicketDataDataContext ctx, TicketEventNotification note, List`1 consolidations) in C:\Projects\TicketDesk\TicketDesk\Engine\NotificationService.cs:line 225
   at TicketDesk.Engine.NotificationService.QueueTicketEventNotification(TicketComment comment) in C:\Projects\TicketDesk\TicketDesk\Engine\NotificationService.cs:line 103
   at TicketDesk.NewTicket.CreateTicketButton_Click(Object sender, EventArgs e) in C:\Projects\TicketDesk\TicketDesk\NewTicket.aspx.cs:line 36
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   --- End of inner exception stack trace ---
   at System.Web.UI.Page.HandleError(Exception e)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP.newticket_aspx.ProcessRequest(HttpContext context) in c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ticketdesk\c4f641c0\e7d3fcc9\App_Web_fofdhqnx.3.cs:line 0
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Sep 17, 2009 at 12:22 AM


No worries on the direct email... I haven't gotten it (which is a little concerning), but I don't mind that you sent it.

A lot of people are confused by the file paths that show up in the stack trace of exceptions. Those paths are based on system where the project was compiled. The compiler created pdb files that contain debugging information, and part of that includes the file paths from the source. It is those paths that show up in stack traces. You can omit the pdb files when you deploy, but that degrades the amount of information exceptions will convey through the stack trace.

Anyway... I can only take educated guesses at the exact circumstances. What I can tell though is that your error is coming from the SubmitChanges() call that you've pinpointed.

In this particular case, the stack trace also tells me that this is happening when the system is attempting to send the broadcast notifications to the help desk users. Unlike regular notifications, which are queued up and sent when a timer expires, the broadcast notifications for new tickets get sent immediately. So the QueueTicketEventNotification() method first creates the notifications, saves them to the database, then loops back though the notifications to see if any are helpdesk broadcasts. If so, it goes ahead and fires the send right then.

In your case though, the notification record in the database has been changed between the time that it was created and the time the system tries to send the notification. Since that is happening during a single method call in the app, it is more than a little odd.

There shouldn't have been enough time for something else to have changed those records in such a small amount of time (we are talking milliseconds between the creation and sending operations here).

It is possible that the record didn't get created for some reason, but that should have thrown a different exception before the point where the system tried to send the notification.

The most likely thing is that something in SQL is change the ticket record as soon as it is created in a way that ticketdesk can't see.  Have you changed the database in any way? Is there some trigger or perhaps a custom default value or something that you may have put on the notifications table?

Assuming you can not find the cause for the notification being changed as soon as it is created, I would suggest you can modify the QueueTicketEventNotification() method as a work-around.  

There is a secton of code at the end of that method that looks like this:


foreach (var note in newNotes)
    if (note.NotifyUserReason == "HelpDesk" && note.NextDeliveryAttemptDate != null)
        SendTicketEventNotificationEmail(ctx, note, new List<TicketEventNotification>());



You can comment that out completely. It will put a slight delay on notificaitons of new tickets for help-desk users, but they will still go out on the very next timer event. That should prevent the error from impacting end-users, and minimize the impact on staff users as well. 




Sep 17, 2009 at 2:20 PM

I appreciate the quick response.

No, I haven't modified anything besides the web.config.  I ran the scripts to create the database.  I have the aspnet tables on the database as well.  The only modification I made to the code was the try/catch block to keep the users from seeing the errors. 

I'll try commenting out the above section of code.  Like I said, there's a weird delay when someone hits submit.  The longer it takes, the more likely the error will show up.  Neither server is under a heavy workload.  The system alllows you to keep hitting submit, and it appears the block of code which looks to see if the rticket already exists doesn't work properly because it creates duplicates anyways.  Just some things to think about. 

Sep 17, 2009 at 4:30 PM

Let me know how commenting that out goes.

I can't say much about the delay or slowness you report. I have pretty much exactly the same environment and setup you describe and performance is pretty decent even with AD in the mix. There certainly is nothing terribly complicated about creating the ticket or the initial set of notifications. I've got first hand reports back from about a dozen moderatly large organizations that use TicketDesk (the 50 to 500 user range), and none of them are reporting severe performance issues. 

The only one that did was just running into problems with the number of sub-groups and non-human users that were in the AD group they had selected for the TicketDesk roles. After they created new AD groups that only included the real people users, that went away for them.



Sep 17, 2009 at 7:00 PM

Ok, so I commented out the above code and removed my try/catch block.  I submitted a ticket and it submitted without delay.  Everything has been responding immediately except that one function and now that is resolved.  I appreciate the help and if you have any other ideas to re-enable immediate emails let me know and I'll be more than happy to experiment.

Sep 17, 2009 at 11:40 PM

I'll work out a different mechanism in TicketDesk 2.0 that doesn't suffer from the potential for this problem. I have no idea why this is coming up in your environment, but it is a very odd problem. The solution is probably to just close out the linq context that was used to create the notification before passing control off to the part that sends the notifications. The work around though shouldn't negatively impact your users too much. 

Sep 17, 2009 at 11:50 PM

Yea, it didn't impact anything at all.  I lowered the mail interval times in the web.config and no one even noticed.  Thank you for your help.