Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

osTicket v1.10 (stable) and Maintenance Release v1.9.15 are now available! Go get it now

[resolved] Overdue Tickets and possible table lock issues

Good morning,
I recently updated from a extremely modified version of 1.6RC to 1.8.12 for our Company.
A couple issues we have noticed since are that everything is getting flagged as overdue, is there a way to disable this and only become overdue if a date is set?

We also seem to have huge delays when replying, opening, or closing tickets. We had this issue before when I was testing, and I feel like it is a locking issue of sorts, as our resources are barely being used. We are definitely noticing it much more now as we have MANY users accessing it as the system is now live.

Any help would be appreciated.


  • The 1.8 tree is old and is no longer supported so I do not think that you will gain much traction [read as: community involvement] on this thread. 

    The overdue flag is a simple 1 or 0 in the isoverdue column in the ost_ticket table entry for a ticket.  There have been numerous database speed enhancements made in newer versions.
  • understood,
    but what keeps setting our tickets as overdue all of a sudden? old system didnt have any, once upgraded, everything went overdue for the most part.

    I will work on the next update.

  • I imagine that the ticket SLA expired.
    Admin panel -> Manage -> SLA
  • I am guessing this is the wrong way to disable overdue alerts?
  • Like I said that version is really old.  I couldn't tell you.
  • ntozier, we are now on version 1.10 (latest)
    the speed issue is still a problem, it almost seems like something is being locked when the system has many people using it.

    Once someone hits to submit a close/new ticker/reply, the screen will just wait for close to 3 mins sometimes, but the ticket does get created, even while the browser window is waiting.

    I am not sure if this is a table lock thing, or something in PHP, but it is definitely some sort of lock.
    I did a test with 3 different browsers, I opened a ticket in one, while it was hung up I opened a different browser, saw the ticket was created, went in an closed it.
    opened a 3rd browser, the ticket was gone, but both other browsers (create new, and close) were still waiting.
    They both completed at the exact same time (possibly once the lock was gone)?
    Let me know what you think I could do to test.
  • I have to add, speed is not an issue for many other folks, including myself. Are you running on a dedicated server or a VPS with a hosting company?

    Also, I do not see what SQL or PHP version you have running, please provide.
  • We are running our OSTicket within a VM (ESXi).
    It is running Ubuntu Server 14.04 LTS
    It is running with 4 cores, and 6GBs of RAM.
    Running from a QNAP RAID10 disk array, over 10GB Ethernet.

    MySQL version is 5.5.53
    PHP is version 5.5.9

    CPU usage is generally around 5%, so it's not like it is being overloaded, resource wise, it is fine.

    As I said, strange thing is, it is always hanging at a confirmation screen (either on open ticket) or it seems to be hanging at the part where it send the email (reply/close).

    Speed wise, the system is great, and extremely responsive, but when creating/closing/editing tickets, the system hangs somewhere...

    I have tried multiple email addresses as sender (gmail and our own dedicated company email) with the same result.

  • Nice little setup :)

    Did you do a clean install, or upgrade from the previous? Could you install a brand new installation elsewhere and test it to see if it has the same symptoms on the same hardware setup?
  • Syntax, here is our story:
    We have been on a highly modified OSTicket 1.6 for about the last 7 years.
    We have come to the point where OSTicket implemented many of the features we had, as well as MANY other improvements we wanted.
    So I setup a local test box, moved the data over and upgraded to 1.9x, had this strange issue occurring on my local machine (i7 8 core, 16 GBs RAM, SSD). Did a fresh install on an ESXi VM, moved our live data over, upgraded, same issue.
    Long story short, I have done about 10 upgrades using a combination of machines, version of ubuntu server, and OSTicket (1.8.12, 1.9x, 1.10). They all have this issue, and it seems to be a bigger deal during business hours.
    I will test again tomorrow morning, but I am pretty sure it does not happen when I am in the office alone around 7 am, but once our locations open around 8am, and other departments begin using the system as well, it just takes a dump...
  • edited January 2017
    I am not saying there isn't an issue, but what i have to say is that everything I have read, people are loving the faster speeds they are getting with v1.10. I am not 100% sure it's OSTicket. But, have you tested a clean install of OSTicket without copying your live data over? 

    Test on a desktop, windows/linux, and see if it is slow locally, copy data over after testing and see if it changes the speed. Then test it like that on ESXI, spin up a VM and test the same way. 

  • edited January 2017
    I was not in early enough this morning to test without everyone else.
    I should be in early tomorrow and be able to test this.

    I have no issues with the speed, navigating is very responsive, definitely better than before.
    it's the posting that is the problem.

    I am not even entirely sure what to do, if for some reason, the issue is our data... we do not want to lose years worth of tickets.

    The other issue with testing a clean install, is that I may not ever see the issue, as there will only be a limited number of users using it, and it may not cause the locking issue.
    I say this because we did not have this issue, with our data, when we tested it internally with just the IT Department (roughly 6 users, not outside clients connecting, etc).

    The only other thing I could think of is that it is maybe some columns I added in ost_ticket when I modded it that are still hanging around? I could try removing them and see if it helps.

    let me know if you can think of anything else...

  • I don't want to jump the gun, but I think I resolved the issue.
    We had one of our email addresses get upgraded incorrectly in the settings, and it would just hang when I tested it through OSTicket.

    I just updated all of the email settings, etc and we seem to be smooth sailing again.

    thank you to everyone who had replied to this ticket 
  • Very nice @jpichie! Wish I was more of assistance but at least you figured it out! May I close this thread now?

    Also, could you explain for others where you made the changes in case they experience this?
  • sure thing syntax
    so something got lost in our upgrade from OST 1.6RC to 1.8.12 for our system emails.
    This carried over to our upgrade to 1.10 a few days later.

    Went to Admin Panel -> Emails

    Click on Diagnostic Menu
    ran the diagnostic for our 2 system emails, one of them just stayed hung up on "LOADING" for about 5 minutes before I closed it. This was similar to the issue we were encountering with out system.

    went to Admin Panel -> Emails -> emails
    click on the 2 emails we have setup and re entered all settings including the passwords.

    Re ran diagnostic, both ran without issues.
    Tested with a couple test tickets, and with 3 of our departments.
    all seems well now.
  • From talking to the devs they say: 

    "if the sla plan is disabled, it shouldn't mark anything as overdue ,that is the default"

    Then he cites the following code: 
     ```            .' AND ((reopened is NULL AND duedate is NULL AND TIME_TO_SEC(TIMEDIFF(NOW(),T1.created))>=T2.grace_period*3600) ' // fresh and overdue
                .' OR (reopened is NOT NULL AND duedate is NULL AND TIME_TO_SEC(TIMEDIFF(NOW(),reopened))>=T2.grace_period*3600) ' // used, go by reopened date
                .' OR (duedate is NOT NULL AND duedate<NOW()) ' // duedate set manually and already passed```
This discussion has been closed.