Yes, in fact, I've been running that SQL command to check for locks, and
sometimes I see that lock on other tables, but that other locks live for
less than a second. However, when the problem happens, the lock on the
auth_user and web2py_session tables remains there for the whole 60 seconds.
Forgot to mention that, when the problem presents in an specific account, I
can experience the same problem if I try to impersonate that account. It
seems as if something would have "break" within that account, and deleting
web2py_session_* rows doesn't help. Actually, until now, the only way I
could "solve" it was creating a new account (of course, that is not
technically a solution) or moving the sessions to Redis.
In case it helps, this is the controller function that processes the post
for the login.
I don't pretend you check all the code, because I'm not sure how this could
be the problem.
def user():
if request.env.request_method == 'POST':
email = request.post_vars.email.lower().strip() if
request.post_vars.email else ''
password = request.post_vars.password
recordarme = bool(int(request.post_vars.recordarme or 0))
errores = []
if not email:
errores.append(['email', 'Ingresa tu dirección de email'])
if not password:
errores.append(['password', 'Ingresa tu contraseña'])
if errores:
return response.json({'success': False, 'errores': errores})
usuario = db(db.auth_user.email.lower() == email).select().first()
if not usuario:
session.failed_login_attempt = True
return response.json({
'success': False,
'message': 'Login data invalid'
})
elif usuario.registration_key:
return response.json({
'success': False,
'message': 'Registration is pending for confirmation'
})
else:
usuario = auth.login_bare(usuario.email, password)
if not usuario:
return response.json({
'success': False,
'message': 'Login data invalid'
})
session.auth.expiration = auth.settings.expiration
if recordarme:
session.auth.expiration = auth.settings.long_expiration
session.auth.remember_me = True
if response.cookies.get(response.session_id_name):
response.cookies[response.session_id_name]["expires"] =
session.auth.expiration
try:
db.auth_event.insert(time_stamp=request.now,
client_ip=request.client, user_id=usuario.id,
origin='auth', description='User %s
Logged-in' % usuario.id)
except:
pass
return response.json({'success': True})
El jueves, 5 de abril de 2018, 17:42:46 (UTC-3), Anthony escribió:
>
> For any select that takes place within a transaction, Postgres by default
> automatically acquires an access share lock on the involved tables, so this
> should be happening on all requests. However, access share locks do not
> conflict with each other, so I don't think these locks are necessarily the
> source of your problem.
>
> Anthony
>
> On Thursday, April 5, 2018 at 10:58:07 AM UTC-4, Lisandro wrote:
>>
>> Hi there! This is somehow related to this other topic [1], which I have
>> closed because I've found some new evidence and I though it would be better
>> to open a new topic.
>>
>> I'm having this problem where a simple select on auth_user table hangs
>> indefinitely, until timeout.
>> The problem occurs in one specific user account. The user logs in, but
>> after the successfull login, any request hangs.
>> I checked the postgres long running queries and I see this query hanging
>> until timeout:
>>
>> SELECT auth_user.id, auth_user.first_name, auth_user.last_name, auth_user
>> .email, auth_user.password, auth_user.registration_key, auth_user.
>> reset_password_key, auth_user.registration_id, auth_user.alta,auth_user.
>> plantel, auth_user.responsable, auth_user.nombre, auth_user.telefono,
>> auth_user.autor, auth_user.foto, auth_user.foto_temp, auth_user.moderador
>> , auth_user.descripcion, auth_user.facebook,auth_user.twitter, auth_user.
>> linkedin, auth_user.gplus FROM auth_user WHERE (auth_user.id = 2) LIMIT 1
>> OFFSET 0;
>>
>>
>> As you see, the query is a simple select to the auth_user table. Also,
>> notice that it uses LIMIT, so it retrieves one only row.
>> Additionally, I can confirm that the table has only four rows.
>>
>> I went a little further, and I checked the pg_locks at postgres when the
>> problem is happening (that is, during the 60 seconds until timeout).
>> This is the query I run to check the locks and this is what I see during
>> that time:
>>
>> select t.relname,l.locktype,page,virtualtransaction,pid,mode,granted from
>> pg_locks l, pg_stat_all_tables t where l.relation=t.relid order by
>> relation asc;
>>
>>
>> relname | locktype | page | virtualtransaction |
>> pid | mode | granted
>>
>> -----------------------------+----------+------+--------------------+------+-----------------+---------
>> pg_class | relation | | 70/908027 |
>> 4421 | AccessShareLock | t
>> pg_index | relation | | 70/908027 |
>> 4421 | AccessShareLock | t
>> pg_namespace | relation | | 70/908027 |
>> 4421 | AccessShareLock | t
>> web2py_session_infosanpedro | relation | | 16/1858255 |
>> 9865 | AccessShareLock | t
>> auth_user | relation | | 16/1858255 |
>> 9865 | AccessShareLock | t
>> (5 rows)
>>
>>
>> *Notice the lock of the web2py_session_* and auth_user tables.*
>> *That lock is there during the whole 60 seconds, until timeout*.
>>
>> After timeout, the lock isn't there anymore.
>> If I reload the page, again, the lock appears and the request hangs until
>> timeout.
>>
>> All the other user accounts can login normally.
>> Also, there is nothing particularly different with the user account
>> having the problem (it's an account like any other else).
>> Of course, I already tried to delete everything from the web2py_session
>> table, but it doesn't work, the problem remains.
>>
>> Where else should I look?
>> Would it help if I share with you the app code for the login? It doesn't
>> do any tricky stuff.
>> What concerns me is that the problem is generated in one specific
>> account, but in several of our customers (we have the same web2py app
>> installed for every one of our customers, each one has its own database).
>> The same problem is happening randomly in a few accounts. Database activity
>> is really low.
>>
>> I'm pretty lost here, so any help or suggestion will be appreciated.
>> Thanks in advance.
>> Regards,
>> Lisandro
>>
>>
>> [1] https://groups.google.com/forum/#!topic/web2py/o0FBeimrr5c
>>
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
