Osticket: 1.10 Lazy lock issue

[kest874]

Not sure why exactly, but if I try to edit a ticket I get the "Your lock is expiring soon.
The lock you hold on this ticket will expire soon. Would you like to renew the lock? prompt. I click "Renew" and it spins forever.

If I submit the reply I get the " This action requires a lock. Please try again" alert. Any idea of the cause?

[jdelhome3578]

I noticed the same thing.

[jdelhome3578]

The lazy lock drop down also covers the ticket floating bar.

[greezybacon]

The lazy lock drop down also covers the ticket floating bar.

That's the idea. It's like a popup but doesn't hijack the screen

[greezybacon]

Can anyone try the patch in #2351?

[jdelhome3578]

Renews once but not a second time. The drop down is still there as soon as I start to type in the response box. Is this intended?

[kest874]

Same result as the original issue.

It does create a lock in the database:

[kest874]

I get this behavior with a brand new install, clone develop-next then setup (clean DB) and try to post a reply to the pre-loaded ticket.

This also happens when I open a new ticket then go try to edit it or post a reply.

[greezybacon]

We merged the patch in #2351 today. Perhaps it had some bearing on the problem

[jdelhome3578]

Just tested from the tip of develop-next and I still have the This action requires a lock. Please try again message. Windows Based IIS 7 php5.5.23 mySQL5.6.11

[jdelhome3578]

I turned off Collision Avoidance and receive this message Unable to lock the ticket. now when trying to reply to a ticket and posting a note. I am using Chrome.

[kest874]

I can now start typing the reply and when I hit "Post Reply" I get the following:

Clicking "OK" I get:

No matter what I get the same lock message.

I noticed that the lock table does not have an entry in it.

Setting Collision Avoidance Duration: to 0 lets me work around the issue now as before it did not.

Anything I can do to help troubleshoot this issue let me know?

[jdelhome3578]

Just tested from the tip of develop-next and I still have the This action requires a lock. Please try again message. Windows Based IIS 7 php5.5.23 mySQL5.6.11

[kest874]

With the latest commits even with the collision avoidance set to 0 I get:

I also tested with a clean slate starting with 1.9.11 and upgrading to 1.10 with the same result.

[balojs]

+1

[jdelhome3578]

Just tested from tip with 1.10 rc1 + 115 commits, still have error This action requires a lock. Please try again

[greezybacon]

@jdelhome3578 I disagree. I feel pretty confident the lock system is working. Perhaps you need to clear your browser cache after updating the codebase

[jdelhome3578]

I cleared cache. Still having issue. Windows Based IIS 8 php5.5.23 mySQL5.6.26 Chrome Browser and IE 11

[jdelhome3578]

@greezybacon

1. I open the ticket
2. I start to type in the response box
3. Your lock is expiring soon. Drops down.
4. I click Post Reply
5. This action requires a lock. Please try again.

Repeat over and over again. I have tried a new server, new install, clear the cache.

[kest874]

@greezybacon

I can duplicate this exactly, not really sure why it isn't working. This happens with a green install as well with all develop-next commits.

Tried with 3 different browsers (Chrome, IE, and Firefox)

[balojs]

me too @kest874

[jdelhome3578]

I have been using the tip of develop-next

[balojs]

develop-next

[jdelhome3578]

@greezybacon

Step by step images

Before Lock:

After Lock before post:

After post:

[greezybacon]

The time: 0 part is the problem. This has been fixed in develop-next with 37a0676b0a6b2d4f94b1cc74276bfe54b5445030

[jdelhome3578]

@greezybacon I have all of those commits in my code and I am still having the issue.

[jdelhome3578]

@greezybacon Just tested again from the tip of develop-next and I am still having the same issue with time: 0

[jdelhome3578]

@greezybacon Tested 1.10 rc2 and I am still having this issue.

[greezybacon]

@jdelhome3578 I'm out of ideas

[balojs]

i have same issue (v1.10-rc.2)

[jdelhome3578]

@balojs are you using iis?

[greezybacon]

What am I doing wrong?

[jdelhome3578]

@greezybacon I have collision avoidance duration set to 3 minutes

[greezybacon]

@jdelhome3578 you previously posted a screenshot of a JSON payload with time: 0. Do you still get such a payload? (It _should_ indicated time: 180).

[jdelhome3578]

@greezybacon I get time: 0 with collision avoidance duration set to 3 minutes

[jdelhome3578]

@greezybacon previous screenshots also had collision avoidance duration set to 3 minutes

[kaptk2]

I too have this issue. Was an upgrade from 1.8.3

[balojs]

thanks Resolved ( Collision Avoidance Duration: 0)

[jdelhome3578]

@balojs I don't consider that a resolution. That just turns Collision Avoidance off.

[jdelhome3578]

@greezybacon Any more on this issue?

[jamesangi]

I posted on the forum before finding this issue, but I just wanted to say "Me Too." I'm running a clean install of 1.10rc2. @greezybacon if there is anything I can do to help troubleshoot let me know.

[greezybacon]

@greezybacon I get time: 0 with collision avoidance duration set to 3 minutes

That's really strange

[greezybacon]

Ok, I think I found it. If php and the database use differing time zones, the lock always appears to be expired and yields a time remaining of zero. Can anyone try the patch in #2533?

[jdelhome3578]

Success {id: 67, time: 180, code: "FJ1WtR3fm5"} :+1: :+1:

[kest874]

I can confirm this works now as well.

[colonelpopcorn]

Works like a charm!

[theodorocaliari]

Yep, this work for me too - https://github.com/osTicket/osTicket-1.8/pull/2533 thanks

[timwhite]

@greezybacon Even with #2533, this still doesn't work for me. I see the locks created in the DB, the time appears correct. However the json returned still has time:0. I set Collision avoidance time to 0, problem goes away (because it doesn't try and lock), once I set it to anything else it doesn't work.

|      11 |        1 | 2016-01-29 18:07:01 | o3OmH9NmnQ | 2016-01-29 18:02:01 |

{"id":11,"time":0,"code":"o3OmH9NmnQ"}

But PHP and MySQL are running in the same timezone (Australia/Brisbane)

[greezybacon]

@timwhite did you pull the rest of the changes for v1.10? There were some timezone conversion issues also addressed in various merges

[timwhite]

@greezybacon I pulled develop-next, which is currently at 364044e, so I believe all the other TZ stuff should be in it?

[timwhite]

Just had a look at the system information page.

PHP Settings
date.timezone    Australia/Brisbane

Database Information and Usage
Timezone    AEST (Interpreted as Australia/Melbourne)

Currently we have Daylight savings time in Melbourne, but not Brisbane. However, AEST should not be daylight savings time. If it's interpreting it as Melbourne though, it will be getting daylight savings time, instead of AEST which hasn't got daylight savings.

Any thoughts on how to fix this?

[greezybacon]

@timwhite Are you able to change the database time zone? Maybe you should specify "Australia/Brisbane" specifically?

[ArmgaSys]

Devs,

We also encountered the "Unable to lock the ticket" issue using the latest tip.
Turns out there are a couple of issues going on:

Environment
MySQL 5.1
IIS 8
PHP 5.6

1st Issue
The ajax.php and dispatcher are not playing nicely with PHP5.6
Under PHP5.6 on IIS, the following error will be fired when the dispatcher returns the JSON payload from ajax.ticket.php
_"PHP Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0"_
This results in the javascript calling the fail: function which displays "Unable to lock the ticket" message.

Solution & Recommendations
1) Modify the php.ini to set always_populate_raw_post_data to -1
2) Modify the message "Unable to lock the ticket" to state an error has occurred
The current message is misleading. It only occurs in an error scenario and has
nothing to do with someone else having a lock.

2nd Issue
The class.lock.php is still susceptible to timezone issues.
This is due to the call to Misc::dbtime and its logic. Basically, Misc::dbtime is attempting to convert the server time (returned by PHP time()) to the timezone equivalent for MySql. In more complex configurations, this can fail as the timezones may not be equivalent.

Recommended Solution
Do not rely on the server time. Ask MySql what it thinks the time is and then compare when checking for Lock expiration and timeouts. (This solution scales to multiple servers better if you ever want to support a web farm)
-OR-
Do not rely on MySql time. When inserting the expiration time, calculate the datetime in PHP using the server time and send the calculated value to MySql (I.E. do not use NOW()). (This solution does not support multiple servers, but will perform better)

[C4RLOCO]

Hi!
I am having issues with the lazy lock as well. Just upgraded to v1.10-RC3

Server Information
osTicket Version v1.10-rc.3 (907ec36)
Web Server Software Apache
MySQL Version 5.5.45
PHP Version 5.6.22

When editing a ticket I get the "Your lock is expiring soon.
The lock you hold on this ticket will expire soon. Would you like to renew the lock? prompt. I click "Renew" and it spins forever.

If I submit the reply I get the " This action requires a lock. Please try again" alert.

[fictionedge]

Hi
I'm having the same problem with 1.10 final version too.
I've already populated the timezone table in the database, set the database time zone, set the timezone in the System Settings and Preferences and in the users profile to be the same but I still get the same error.

[demogar]

Still present on the latest available version. Had to turn off the lazy lock functionality.

[iHunt101]

Got this one too. Can we have a check box like for this functionalty to turn if off if we dont need it? @greezybacon

[dogatemycomputer]

+1

[bedo2991]

I am getting the same problem, fresh installation.
The lock is saved correctly in the database, but the ajax function returns: "time:0" with a _Collision Avoidance Duration_ set to 3 minutes.

---

Eureka! I found out the source of the problem (and it was not a software bug). I have the database hosted on a different machine, and this machine had a wrong time set (it was 5 minutes behind the actual time). For this reason, setting up a _Collision Avoidance Duration_ lower than 5 minutes caused all the problem stated above.

Maybe during the installation process there should be a check about the synchronization between the database and the php time...

[adrianogoncalves]

@greezybacon That's it! Thanks!

[neoand]

Collision Avoidance equal to 0 zero and is resolved !

[piojesio]

The problem has revelead after implementing Fix "unions with sorting on the main query" https://github.com/osTicket/osTicket/commit/e17a9124e7c59d6de7ae21a8e736740b837badec#diff-8a9a2e8df39a44fd83995d685f4eab88
After restoring previous version of class.orm.php file it works properly and sorting still works as well.

[cocuba]

Collision Avoidance equal to 0 zero and is resolved for me!