Re: PATCH/s: RM#1387 - Bad handling of missing connection database server

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: PATCH/s: RM#1387 - Bad handling of missing connection database server
Дата
Msg-id CA+OCxoz0hweSZj79S=fM-SD9YFZJU4AM2BY7fM++BDWU+UbcCQ@mail.gmail.com
обсуждение исходный текст
Ответ на PATCH/s: RM#1387 - Bad handling of missing connection database server  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Ответы Re: PATCH/s: RM#1387 - Bad handling of missing connection database server  (Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
Список pgadmin-hackers
Hi

Can you re-base please? The nodes patch no longer applies.

Ignoring that conflict though, the first test I did was to restart the app server when connected to a database. I then (after it restarted) to open the Schemas node in that database; nothing happened at all in the client, but on the server I saw:

2016-08-19 16:59:16,321: INFO werkzeug: 127.0.0.1 - - [19/Aug/2016 16:59:16] "GET /browser/schema/nodes/1/1/219759/ HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 2000, in __call__
    return self.wsgi_app(environ, start_response)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1991, in wsgi_app
    response = self.make_response(self.handle_exception(e))
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1567, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1988, in wsgi_app
    response = self.full_dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1641, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1544, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1639, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/app.py", line 1625, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/Users/dpage/.virtualenvs/pgadmin4/lib/python2.7/site-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/utils.py", line 235, in dispatch_request
    return method(*args, **kwargs)
  File "/Users/dpage/git/pgadmin4/web/pgadmin/browser/server_groups/servers/databases/schemas/__init__.py", line 129, in wrap
    self.conn = self.manager.connection(did=kwargs['did'])
  File "/Users/dpage/git/pgadmin4/web/pgadmin/utils/driver/psycopg2/__init__.py", line 1330, in connection
    raise Exception(msg_active_conn)

I realise it could well be caused by the conflict when applying the nodes patch, but just in case it's not... :-)

On Fri, Aug 19, 2016 at 12:25 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
Hi Dave/Team,

I have attached three patches targeting specific area of work.

-> backend_connection_status_management
* Takes care of the connection status in the psycopg2 driver. And, when the connection is lost, it throws a exception with 503 http status message, and connection lost information in it.
* Contains a change to allow to the flask application to propagate the exceptions even in the release mode.
* Modification for utilising the existing password (while reconnection, if not disconnected explicitly).
* Introduced a new ajax response message 'service_unavailable' (http status code: 503), which suggests temporary service unavailable.

-> manage_client_connect_lost
* It handles the connection lost for different operations at client (browser) side.
* Using the events to handle this situation.

-> remove_connection_status_check
* We're currently return precondition_required (HTTP status code: 428) for the same, but - there is no consistent message/information available to identify it reliably as the server connection lost error (client side changes takes care of this situation, but - this patch is recommended for the whole change to work properly). This patch removes the connection status check from the individual nodes.


TODO:
* Browser tree - node expansion
- When there is an error occurred during expanding the aci-tree node, it does not let the client handle the issue based on the status code, and error message, as it does not expose/share the error details with us. We will have to hack the aci-tree for the same.

* Query Editor
- Slick grid changes are in progress, hence - I did not touch the code for it, as it will lead to rework for either one of us (me, or Murtuza). I will take care of it as soon as the slick grid changes will be committed.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company


http://www.linkedin.com/in/asheshvashi




--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

В списке pgadmin-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: [pgAdmin4][Patch]: RM1570 - Cannot select template databases when creating a database
Следующее
От: Surinder Kumar
Дата:
Сообщение: [pgAdmin4][Patch]: RM1569 - Right-clicking an disconnected EPAS server shows "Create Resource Group" option