Most users can simply leave these settings at their default values. Unless otherwise specified, a change in any of these settings takes place immediately, even if the server is already running.
The Panorama X Server application normally runs completely in the background. It has no windows, and is controlled from the Preferences>Server panel (used from a regular copy of Panorama on the same computer). Since there is no user interface, normally Panorama X does not display a dock icon. If you want it to, check this option and the dock icon will show up the next time you launch the server.
We don’t recommend using this option, because if you click on the dock icon there is no user interface. Even if you want to the server to quit, you should do that by pressing the Stop Panorama X Server button in the Preferences>Server panel.
Please note that this option does not take effect immediately, the dock icon only appears or disappears the next time you start the server. So if the server is already running, you must stop it and then start it again to see the change in the dock.
Panorama X Server normally runs as a regular application. If you check this option, however, Panorama will first launch Terminal.app (or open a new terminal window if Terminal.app is already running), then it will run Panorama X Server from within the terminal window. This is very useful for debugging web code, because you can use the stdout or nslog statements to output debugging messages to the terminal window (more on this in a moment). This illustration shows what the terminal window looks like when Panorama X Server starts up. (For clarity, the Panorama X Server app is being displayed in the dock, but this is not necessary.)
Any console output generated by Panorama X Server will be displayed in this terminal window. You can add the stdout or nslog statements to your code to display text in the terminal window. This is kind of like using a message statement for debugging, but no alert appears and these statements don’t interfere with the operation of the server.
For example, suppose you have a web procedure like this, with two stdout statements.
When you enter the URL for this procedure into your browser, the server runs the code and generates HTML, which is displayed in the browser like this.
But if you look in the terminal window, you’ll see that the output from the stdout statements are displayed there.
This is especially useful if your code doesn’t work correctly. You can put stdout or nslog statements in your code to display intermediate results and see what the flow of the code is actually doing, right on the live server.
Once your code is debugged and working, you can remove the stdout or nslog statements if you wish. Or, you can leave them in – if Panorama X Server is not running using Terminal.app, these statements are automatically ignored.
Note: If Panorama X Server is running, you should not close the terminal window or quit the Terminal application. If you do, it will force Panorama X Server to quit (you will be prompted before this happens). We recommend using the Stop Panorama X Server button in the Server Preferences panel to stop the server. When you do this, you’ll see a message in the terminal window confirming that the server has shut down.
At this point it is safe to close the terminal window and quit Terminal.app if you don’t plan to use it any further.
If a procedure contains a loop that isn’t written correctly, it can continue running endlessly (see Preventing Endless Loops. If this happens in a web procedure, the server will stop responding to clients and will have to be shut down (force quit) and restarted. To prevent this, the server will automatically stop any web procedure that runs for more than 20 seconds. You can adjust this time limit to make it longer or shorter using the Procedure timeout setting. (You can even turn the timeout off completely, but we strongly discourage this.) If a web procedure exceeds the maximum allowed time, an error message will be displayed on the client web browser.
You can also use the timelimit statement to customize the limit in individual web procedures. This statement overrides the setting in the preferences panel. For example, you might want to set the preference to a short timeout, like 5 seconds. But if you have one particular web procedure that you know is likely to take more time, you can use the timelimit statement to allow that procedure to run without an error. Keep in mind, however, that the server can only process one web procedure at a time, so you should always strive to make web procedures run as fast as possible, ideally well under a second if possible.
The Preferences>Logging panel allows you to specify what server activities should be recorded for possible later analysis (see Logging Server Activity. Normally these activities are saved in text files for later review, but you can also request that this activity be displayed in a terminal window.
Of course this option only works if Panorama X Server is running under a terminal window as explained in the previous section. If Panorama X Server is not running using a terminal window, this option is ignored.
In addition to your debugging code, Panorama X’s internal web server can output debugging information to the terminal window. There would usually never be any reason for you to enable this, since you cannot debug this internal code, but if a ProVUE technician asks you to enable debug messages for the internal web server, this pop-up menu would be the way to do that.
This setting controls the HTTP port used by the internal web server. Usually this is is set to 8080, but you can change it to any value from 1000 to 65535. Because of restrictions built into macOS, you cannot set the port to 80. If you need to use port 80 (the most common port for public web servers), you must set up Apache or another external web server. See Using an External Web Server to learn more.
The internal web server will normally accept connections from clients on any computer. However, if you enable the Local Connections Only option, it will only allow connections from the server computer itself. You should only enable this option if you are using an external web server (see Using an External Web Server). Setting this option prevents outside clients from bypassing the external web server and contacting Panorama’s internal web server directly. Normally this isn’t an issue but we’ve found that malicious web robots can attempt to contact and disrupt the internal server, sometimes causing crashes and server overloads. Setting the Local Connections Only option eliminates this potential attack vector and increases the security of your server. (On the other hand, setting this option prevents the server from being accessed by Bonjour on the local network, so you should only enable this option if you don’t plan on connecting to the server via Bonjour. For example, we use this option with the provue.com server, which is located on a remote server in a colocation facility, not on our local network.)
When publishing web pages, the Panorama server sometimes needs to create links to other pages or images on the web server. To do that, it needs to know the URL of the web server. The server can’t figure this out by itself, so you’ll have to tell it what its IP address or domain name is. (If you are only using the server for database sharing, you can skip this section and leave the default domain setting,
<internal>). You can set the IP address or domain name either by typing it in with the keyboard (for example www.acmewidgets.com), or choosing from four preset values in the popup menu.
The four popup choices are:
When changes are made to a shared database, the changes aren’t saved from memory to the disk immediately. Instead, the server waits for a short time before saving to disk. If multiple changes are made within this delay period, performance is enhanced because the save operation is only performed once, not once for every change. This delay is normally set to one second. You can improve performance by increasing the delay, thus reducing the frequency of time consuming save operations. This is especially beneficial if your databases are large. Of course the potential downside is possible data loss if the server crashes before the data is saved. You can protect against that risk by enabling the transaction journal option, described in the next section.
When the transaction journal option is enabled, Panorama X server will keep a record of all unsaved changes made to each server database. If a database is large, saving each change in the transaction journal can be much faster than immediately saving the entire database every time a change is made. In the unlikely event that the server crashes before the changes can be saved, Panorama X Server will restore the unsaved changes from this journal the next time the database is opened on the server. This is especially useful if you increase the auto save timeout as described in the previous section.
Since the transaction journal contains only unsaved changes, the journal is cleared automatically whenever the database is saved. This keeps the journal size down to a manageable level.
When a client locks a database record, the server normally maintains that lock until that same client releases it. But what if that client goes offline for some reason – perhaps the computer goes to sleep or loses its internet connection. In that situation, the server can be configured to automatically release the lock if another client requests to edit that record.
After a client locks a record, it periodically “pings” the server to tell the server keep the lock alive. As long as the server receives these pings, it will never release the record to another user. But if the pings stop coming through, the server can release the lock. However, it won’t do so unless another users requests to edit that specific record. If no one else requests to edit that record, the lock will be maintained indefinitely, so that if the original client manages to re-connect they will be able to complete the editing they were working on.
The auto-unlock feature is enabled by setting the Auto Lock Timeout to a value greater than zero. This setting specifies the minimum number of seconds before the server can consider the record lock as “abandoned.” If another users tries to edit the record before the timeout period, the server will reject their editing request, telling the second user that the record is locked.
We suggest that if you use this feature, the timeout should be set to at least 45 seconds, and ideally significantly more than that (for example 300 for 5 minutes). This will allow a client to drop the connection for a short time without risking giving up their record lock (and losing whatever data editing they were working on).
Keep in mind that this setting is for a server timeout on the record lock. The setting only affects the server, and only applies if the connection from the client to the server is broken.
Panorama also has an record lock option on the client end. This is enabled in the Database Options>Sharing panel, as described in Record Locking and Editing Shared Data. If a user starts to edit a record and then walks away for some reason, this timeout will kick in and complete the edit for them, allowing other users to edit the record. Auto-unlock on the client side does not have any possibility of data loss – it works as if the user had manually finished the edit. However, client-side auto-unlock does rely on a working connection between the client and server, it won’t work if the connection is broken for any reason (network drops, computer lid is shut, etc.). The server side auto-unlock can be a useful backup for situations where the connection is unreliable.
Of course even without server side auto-unlock enabled, you can always manually unlock a record using the Server Administration Wizard. See Locked Records on that page to learn how to manually unlock a record using this wizard.
When processing a web request to publish or modify a database, Panorama Server first opens the database, processes the request, then closes the database. However, it doesn’t close the database immediately. Instead, it waits for the specified delay time before closing the database. If multiple requests come in for the same database in a short period of time, this can dramatically improve performance by eliminating the extra time needed to open and close the database.
It is also possible to specify that a database should be opened into memory automatically when the server starts up, and kept open all the time until the server is stopped. This is done with the Open automatically when server starts up option in the Database Options>Server panel. If this option is enabled, the auto close delay is ignored for that database, since the database is kept open all the time on the server.
Also keep in mind that if a database is open for sharing by one or more clients, it will always be kept open on the server. As long as the database is open for sharing, the auto close delay doesn’t apply to that database.
|10.2||New||New in this version.|