The Meta implementation inside of the Avatica server is a singleton, so
yes the implementation must be threadsafe as the server will dispatch
multiple user request threads to it. The Meta implementation is largely
(by virtue of the wire API) stateless. I think the expectation should be
that all Meta implementations are threadsafe, but this probably isn't
something anything has really looked long and hard at.
On 2/14/19 3:15 PM, Vladimir Sitnikov wrote:
Hi,
CalciteRemoteDriverTest seems to be very unstable at
https://builds.apache.org/job/Calcite-Master/
I guess the problem there is the test is using a single CalciteMetaImpl
object to handle all the requests.
Apparently CalciteMetaImpl is using no synchronization and it uses simple
HashMaps (Meta is associated with exactly one Connection which is not
thread-safe).
I wonder:
1) Is org.apache.calcite.avatica.Meta supposed to be thread-safe? Javadoc
does not clarify that. It looks
like org.apache.calcite.avatica.jdbc.JdbcMeta is thread-safe.
2) In case Meta is supposed to be thread-safe,
why org.apache.calcite.avatica.MetaImpl has Connection constructor? Does
Avatica suppose that all connection implementations are thread-safe?
3) In case Meta is supposed to be thread-safe, how MetaImpl#connProps is
supposed to work? Apparently different connections might have different
properties (e.g. autocommit settings), so how a single connProps would fit
all?
4) In case Meta is not supposed to be thread-safe,
why org.apache.calcite.avatica.server.Main#start uses just a single Meta
object to handle all the requests?
5) Does anybody use CalciteRemoteServer at all?
I don't have Calcite-remote use-cases yet, however the current state of
builds.apache.org is useless as it fails extremely often.
Vladimir
