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

On Fri, Aug 19, 2016 at 9:32 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> 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:
>
This exception suggests that - pgAdmin 4 was not able to establish the
connection again during restarting it.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company
<http://www.enterprisedb.com/>

*http://www.linkedin.com/in/asheshvashi*
<http://www.linkedin.com/in/asheshvashi>

>
> 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(dot)vashi(at)enterprisedb(dot)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.enterprisedb.com>
>>
>>
>> *http://www.linkedin.com/in/asheshvashi*
>> <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
>