[INSTRM-530] Possible failure in OBCP getFrames() internals Created: 19/Oct/18  Updated: 09/Nov/18  Resolved: 09/Nov/18

Status: Won't Fix
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: cloomis Assignee: eric
Resolution: Won't Fix Votes: 0
Labels: MCS
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The g2sim3 server had an internal failure when allocating a new frame. Looks like a disconnection from the database server.

Is this a one-off thing? Should we be prepared for .getFrames() failures?

Finally, sorry for the impressively escaped log segment.

2018-10-18 18:49:37.4383Z > 'client.v209 9 getVisit\n'
2018-10-18 18:49:37.5448Z < '2 9 f text="command failed: CamInterfaceError(remoteObjectError(\'Method call .getFrames failed to g2sim3.subaru.nao.ac.jp:8161: <Fault 1: \\"<class \\\\\'SOSS.frame.SOSS_frame.frameError\\\\\'>:Error obtaining frames: (psycopg2.OperationalError) server closed the connection unexpectedly\\\\\\\\n\\\\\\\\tThis probably means the server terminated abnormally\\\\\\\\n\\\\\\\\tbefore or while processing the request.\\\\\\\\n [SQL: \\\\\'SELECT instrument.number AS instrument_number, instrument.shortname AS instrument_shortname, instrument.fullname AS instrument_fullname, instrument.code AS instrument_code, instrument.year AS instrument_year, instrument.description AS instrument_description, instrument.meta AS instrument_meta \\\\\\\\\\\\\\\\nFROM instrument \\\\\\\\\\\\\\\\nWHERE instrument.shortname = %(shortname_1)s\\\\\'] [parameters: {\\\\\'shortname_1\\\\\': \\\\\'PFS\\\\\'}] (Background on this error at: http://sqlalche.me/e/e3q8)\\">\\\\n  File \\"/software/mhs/products/Linux64/ics_gen2Actor/1.3.0/g2cam/g2base/remoteObjects/remoteObjects.py\\", line 521, in call_remote\\\\n    res = client.proxy.call(attrname, args, kwdargs)\\\\n  File \\"/software/mhs/products/Linux64/ics_gen2Actor/1.3.0/g2cam/g2base/remoteObjects/ro_XMLRPC.py\\", line 75, in call\\\\n    return method(*args, **kwdargs)\\\\n  File \\"/software/conda/lib/python3.6/xmlrpc/client.py\\", line 1112, in __call__\\\\n    return self.__send(self.__name, args)\\\\n  File \\"/software/conda/lib/python3.6/xmlrpc/client.py\\", line 1452, in __request\\\\n    verbose=self.__verbose\\\\n  File \\"/software/conda/lib/python3.6/xmlrpc/client.py\\", line 1154, in request\\\\n    return self.single_request(host, handler, request_body, verbose)\\\\n  File \\"/software/conda/lib/python3.6/xmlrpc/client.py\\", line 1170, in single_request\\\\n    return self.parse_response(resp)\\\\n  File \\"/software/conda/lib/python3.6/xmlrpc/client.py\\", line 1342, in parse_response\\\\n    return u.close()\\\\n  File \\"/software/conda/lib/python3.6/xmlrpc/client.py\\", line 656, in close\\\\n    raise Fault(**self._stack[0])\\\\n\',),) at /software/mhs/products/Linux64/ics_gen2Actor/1.3.0/g2cam/g2cam/Instrument.py:879"'


 Comments   
Comment by cloomis [ 19/Oct/18 ]

After talking with Eric I'll declare this a one-off, but one which we should track. Not sure whether we should close this quite yet. @hassan can decide.

Comment by hassan [ 19/Oct/18 ]

I'm tempted to keep this going for at least the period of the engineering run.

Comment by cloomis [ 09/Nov/18 ]

Did not show up again.

Generated at Sat Feb 10 16:25:58 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.