From: | Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com> |
---|---|
To: | Dave Page <dpage(at)pgadmin(dot)org> |
Cc: | pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: PATCH/s: RM#1387 - Bad handling of missing connection database server |
Date: | 2016-08-24 05:55:31 |
Message-ID: | CAG7mmoxLNZupbX7BKm18XMgp8G+05ZBMzgrjy4BJz_svoxhSFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
Hi Team,
On Sun, Aug 21, 2016 at 3:55 PM, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com
> wrote:
> On Aug 21, 2016 15:08, "Dave Page" <dpage(at)pgadmin(dot)org> wrote:
> >
> > Yeah, but shouldn't it be caught and handled, with a suitable retry
> yes/no in the UI?
> And, that realised me, I missed one case, on which I am already working.
>
Please find the updated patches.
--
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>
> --
> Thanks & Regards,
>
> Ashesh Vashi
> >
> >
> > --
> > Dave Page
> > Blog: http://pgsnake.blogspot.com
> > Twitter: @pgsnake
> >
> > EnterpriseDB UK:http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
> >
> > On 20 Aug 2016, at 12:03, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com>
> wrote:
> >
> >> 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.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.linkedin.com/in/asheshvashi
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Dave Page
> >>> Blog: http://pgsnake.blogspot.com
> >>> Twitter: @pgsnake
> >>>
> >>> EnterpriseDB UK: http://www.enterprisedb.com
> >>> The Enterprise PostgreSQL Company
> >>
> >>
>
>
Attachment | Content-Type | Size |
---|---|---|
backend_connection_status_management_v2.patch | application/octet-stream | 14.1 KB |
manage_client_connect_lost_v2.patch | application/octet-stream | 43.9 KB |
nodes_connection_status_v2.patch | application/octet-stream | 75.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Murtuza Zabuawala | 2016-08-24 05:55:44 | Re: Fixed RM #1209 Trigger issues through right click |
Previous Message | Murtuza Zabuawala | 2016-08-24 05:00:46 | Re: Fixed RM #1209 Trigger issues through right click |