Hi list,
Scheduled for next year is the (alpha/beta) release of MonetDB/Five, the
successor of the current MonetDB generation. MonetDB/Five is the
logical successor to its predecessor in terms of speed and performance.
However, MonetDB/Five is not fully backwards compatible with it's
predecessor. Instead of using the MIL language for kernel operations,
it uses MAL. Although many MIL operations can be easily mapped on MAL
operations, a fully automatic (and correct) translation of MIL to MAL is
not possible. Directly related to this, is the availability of
MonetDB/XQuery, which currently heavily relies on the MIL language. The
SQL users of MonetDB will be the only ones that will immediately
benefit from the improved MonetDB/Five engine, as SQL is fully
functional and there is no difference in language or output.
Due to this situation where both M4 (curent MonetDB generation) and M5
(MonetDB/Five generation) have it's own advantages (XQuery support, MIL,
MAL, better performance) it is most likely that one would like to run
both M4 and M5 engines next to each other to benefit from both. This
would currently cause problems when applied out of the box.
Given that M4 and M5 would be slotted, and hence installable next to
each other, starting it's services would cause problems because both
engines try to bind to the same ports by default. To give a short view
on the ports in use by default:
M4 M5
Mapi 50000 50000
SQL 45123 45123
XQuery 45789 N/A
This obviously clases for default MIL/MAL (Mapi) connections as well as
SQL connections. XQuery is not an issue for the moment. A few
observations:
- The actual language spoken over the Mapi server port is engine
specific, i.e. MIL for M4 and MAL for M5. This is probably somewhat
confusing. For SQL it is clear, and the port specifies which language
to use, regardless the engine.
- XQuery support is not available for M5 yet, but it should be dealt
with as for SQL.
Possible scenarios to solve the problems of clashing ports can be:
1. Use different port numbers based on the engine, i.e. use 55123 for
SQL on M5 and 45123 on M4. Mapi could become something like 50005
for M5.
2. Build (or extend for instance the DatabasePool) an application that
handles transparently the request for a service making use of a
combination of port and challenge response to give the client a M4
MIL, M5 MAL, M5 SQL or M4 XQuery connection, using the ports
currently known. (Note: this also allows for multi-catalog support
for SQL, when the DatabasePool is taken as base.)
3. Ignore the problem and only document it, including how to change the
default ports to avoid clashes. (Note: unfortunately we're unable to
bind to a certain interface...)
4. A combination between 1 and 2, with the purpose of getting each
language it's own port in the system, reducing the problem and
possibly disable M4's SQL server.
Are end-users interested in/aided by such changes made, or will they
figure out themselves easily enough? Just a few thoughts on a problem
that will arise in distribution land...
