How does Octopus manage port usage, and how does this relate to the port number specified in the nucleus.ini file?
Octopus dynamically assigns port numbers for connection to the OctoEng's that it starts automatically. Since a maximum of 50 running OctoEng's is permitted, the Octopus system reserves fifty port numbers for use with each Octopus database. To avoid conflict with other Octopus instances, a restriction is imposed requiring that the difference between the Port values in the OCTOPUS sections for each instance be greater than 50 (this restriction can be overridden by using the StartPort parameter).
If the value of Port is between 1024 and 5000, Octopus automatically adds 5000 to the number and then reserves the next fifty ports. Note that the original port number is still used for Octopus client connections, and the port+1 port is reserved for internal management operations. Therefore when the port is set to 3000, Octopus actually reserves and uses the following ports: 3000 (clients), 3001 (internal), 8002-8051 (OctoEng's).
If an OctoEng is killed while executing a query, Octopus will automatically restart that OctoEng. Will it also restart the query?
The query will not be rescheduled; the user will receive an error (O0203E Communication lost between OctoEng: node-name_class-name_number and Octopus).
Say an Octopus instance is configured with a HEAVY class (RescheduleTimeout=0) comprising 2 OctoEngs and a LIGHT class (RescheduleTimeout=5) comprising 1 OctoEng. If three long-running queries are submitted, what will happen to the third query after it is scheduled on the last remaining class (light), and then gets cancelled after 5 seconds?
The query will be queued for execution by the first free OctoEng in the HEAVY class.
If a load fails while Octopus is operating in Public Update mode, will all the changes be lost?
In Public Update mode, if the loader fails but the Update OctoEng continues to run, it is still possible to perform a KEEP CHANGE that will incorporate changes up to the latest COMMIT WORK command. However, if the Update OctoEng fails during a load, it will subsequently restart using the current entry point (DB_VERSION x.0), meaning that the database will be as it was after the last KEEP CHANGE.
Execution of Data Definition and Data Manipulation Commands in Private Update Mode
In Private Update mode, DDL and DML statements (i.e. CREATE..., INSERT, UPDATE, DELETE etc.) are always queued for execution by an OctoEng in the heaviest class of execution. This is designed to protect the execution logic of subsequent statements, since if a command needed to be rescheduled for execution on another OctoEng, a new transaction would be started and the previous changes discarded.
As an example, consider what would happen if a CREATE TABLE statement ran on a light Class and was followed by an INSERT ... SELECT command inserting data into that table. If the INSERT timed out, it would be rescheduled to run on a heavier class � however, the "CREATE TABLE" would not be rerun, so the INSERT would fail with a "non-existent table" error.