Sending data to FileMaker from external sources poses interesting options and challenges.
One of our development projects required enabling ODB/JDBC and sending data via JDBC (Java Database Connectivity). The sending application used FileMaker’s client driver, which allowed it to send SQL insert statements to the FileMaker database via FileMaker Server. This required Server Advanced, and enabling ODBC/JDBC in the server settings:
This process worked seamlessly, as long as FileMaker’s “fmxdbc_listener” process remained active. But, in our non-perfect world, sometimes this process failed.
Even though the configuration setting remained checked in the Admin Console, the process simply stopped, and our database no longer would accept incoming connections from the Java app. Unless someone happened to watch the process, hours or days could pass before anyone noticed this problem. We needed a method to monitor the fmxdbc_listener process. (Since the servers run on Mac OS X, this solution is not cross-platform.)
Activity Monitor showed all FileMaker Server processes, when filtered by “fm”:
While the Activity Monitor provided a good user interface to see all system processes, we needed to automate and script the scenario.
The command line script was something that could be automated. Using “ps” we could view different processes. Targeting one specific process required adding “grep”, such with this command:
ps aux | grep '[f]mxdbc_listener'
This generated an output when the process ran:
fmserver 624 0.0 2.3 213008 97120 ?? S 9:49AM 0:00.27 ./fmxdbc_listener
If the process went offline, the Terminal showed an empty process. This could then be written as a shell script, or in our case, a PHP command line script with the option to send an email.
#!/usr/bin/php -q
<?php
error_reporting(0);
$fmx = exec("ps aux | grep '[f]mxdbc_listener'");
if(empty($fmx)) {
$to = 'admin_group@server_name.com';
$subject = 'XDBC Listener unavailable';
$message = 'Reset process';
$headers = 'From: admin@xdbc_server.com' . "\r\n" .
'Reply-To: admin@xdbc_server.com' . "\r\n" .
'X-Mailer: PHP/' . phpversion();
$mail = mail($to, $subject, $message, $headers);
}
?>
When we moved the code to the server it failed to generate an email. Since the server resided inside a firewall, we switched to an internal FileMaker process instead. Using the PHP API, we triggered a FileMaker script in a monitoring/logging database, which sent the email via SMTP, a process we already used on other databases on that server and knew would work.
#!/usr/bin/php -q
<?php
error_reporting(0);
require_once('FileMaker.php');
define('FM_HOST', 'IP_Address');
define('FM_FILE', 'xdbcLog.fp7');
define('FM_USER', 'web');
define('FM_PASS', 'web');
$fm = new FileMaker( FM_FILE, FM_HOST);
$fm->SetProperty( 'username', FM_USER );
$fm->SetProperty( 'password', FM_PASS );
$fmLayout = 'Log';
$scriptName = 'Send_eMail';
$fmx = exec("ps aux | grep '[f]mxdbc_listener'");
if(empty($fmx)) {
$script = $fm->newPerformScriptCommand( $fmLayout, $scriptName);
$result = $script->execute();
}
?>
To automate this process we enabled it as a cron job, checking the server every few minutes. To reactivate the process, you could simply uncheck the ODBC configuration, save your action, check it again, and save once more. So, although human intervention is required to restart the process, setting up this system script send an immediate alert when the process is detected as offline. Whether this is foolproof method for process-monitoring remains to be seen. Why the process fails is another question. If other FileMaker developers have encountered similar issues, I would be interested in hearing how you have dealt with this issue, both on Mac and Windows servers.
tasklist /FO "IMAGENAME eq fmxdbc_listener.exe" /FO CSV > C:\fmxdbc.csvrun from a windows command line will get you a text file that show if the process is running. It will put text similar to the following in the file if the process is not running:
“INFO: No tasks are running which match the specified criteria.”
Since you can output that to what ever folder you want, you could put that in a batch file that leaves the .csv file in a spot that FM Server could pick it up. A server side script sequence could deal with a sending an email based on the contents of the .CSV file.
Just a thought.
~Mark
Thanks, Mark! That’s very good to know.
The above code has a typo. It should be:
tasklist /FI “IMAGENAME eq fmxdbc_listener.exe” /FO CSV > C:\fmxdbc.csv
Happens to me as well. Quite frustrating to say the least. I’m interested in hearing how to automate the process of turning the listener back on as well. I’d like to exploit Java or groovy in our FMS11 environment but don’t think think I can do this in production w/the listener shutting down on me for know [apparent] reason.
So far I haven’t found a way to automate turning the listener process back on after it crashes. That would be ideal, but right now we just use the manual process of disabling ODBC and re-enabling it.
I assume you’ve made this known to FileMaker systems engineers because most of us normal people just expect such services to work without our intervention. What OS was this on? Snow Leopard? Lion? Was it a Server version of Mac OS X? It make she wonder if this doesn’t happen on Windows. But quite an interesting topic and know we sometimes have to make workarounds when things are perfect.
The process has been too inconsistent to pin down exactly when this happens for the engineers to review. The sever runs on Snow Leopard, and on a server version of Mac OS X. We’ve had times where the JDBC connections come in fairly quickly, and from three servers, which might overwhelm the FM Server, but there are times it works for weeks or months without any issues, and then times where it crashes fairly often in the same day, with no changes to the JDBC connections. Unfortunately the server diagnostics don’t say much about what could cause this.
I have found that when the FileMaker Server Admin console shows the XDBC client with an “In Progress” value of 40, the fmxdbc_listener.exe stops processing well and the threads shown in the Windows Task manager begin to climb uncontrollably. Changing the process Base priority does not seem to improve this nor does using cleanmem. I am working with an environment that has around 700-950 concurrent connections and tends to have small “floods” of ODBC connections. When this all happens the ODBC connections get stuck and never drop off.
Hi Steve, thanks for dropping by and providing this insight.
we are running into the exact same problem. We are making some connections via jdbc with coldfusion.. no more than 5 connection and after 2 or 3 minutes the listener crashes.. I posted some info about it in the forum
http://forums.filemaker.com/posts/8f3f6a5d4d?commentId=227620#227620
I migrated all the solution from windows to mac to see if this would fix the problem but still crashes..
I am not sure I can afford to just cycle the process 🙁 .. I also called filemaker about it and the just say that they cant do anything.. that the connector was made by a third party.. what a hell !!! .. I am so mad there is not a single debug mode to see a trace and determine whats causing the problem.
has anybody found a solution on this?
by the way Anders, is this happened in fm11 or 12? Our case is 12 v3.. mac and windows versions (server).
Guillermo, we had a similar issue with 3 connections, where after a short while the number of connections from the 3 servers would not drop, but each one had multiple connections. This was with server 10 or 11. I am not sure how the IT group fixed this, but they set up the connections to remain open, not open and close with each request. That seemed to solve 99% of the issue.
With FMS 12 you now also can use the command line to start the XDBC process, which eliminates the need to open the admin console and check the box to start it up again. I don’t know if that would help, since it’s a band aid, not a solution.
Anders
I am experiencing a very similar issue with our recently implemented Windows-based FMSA12. Only 5-7 ODBC connections are established once an hour, and the xDBC listener dies every other day.
Anders,
You mentioned there’s a way to restart the listener via command line; can you share that code? I’d like to set up a system event task to restart the listener each day after work hours (when no ODBC connections are attempted).
Adam, check the two sections at the top of the post starting with the “#!/usr/bin/php -q” command. These are variations on how to check for the listener status.
For FMS 11 and older we had to manually restart the listener. If you have FileMaker Server 12, you can use the new restart command:
RESTART XDBC
In the Terminal, run the command “fmsadmin help restart” for more details on the different options.
Regards,
Anders
For FMSA v11 running on Windows, my goal wasn’t just to monitor the process (for which I also have a complete solution not documented here), but to restart the fmxdbc_listener process automatically in the event the process has quit. The solution is quite easy: Just create a batch file in your FileMaker Server/Data/Scripts folder that starts the process:
echo off
REM written by David Ness 5/14/2014
REM Starts the fmxdbc_listener process, necessary for ODBC connections to FileMaker.
REM This batch script will work even if the process is already running.
REM If the process is already running, that process is left running,
REM and new instances will fail to start, which is what we want to happen.
"C:\Program Files (x86)\FileMaker\FileMaker Server\Database Server\Extensions\xDBC Support\fmxdbc_listener.exe"
Then just set up a server scheduled to run the System-Level script at regular intervals. I run it every hour, just before I know another user has a scripted process using the ODBC connection to read data from FileMaker. As the REMarks state, this works fine even if the fmxdbc_listener process is already running, as subsequent instances of the process will fail to start, leaving just the original one, and only one, running. The only downside is that this doesn’t automatically restart the process instantly upon the process quitting, but you can increase or decrease the frequency as your needs demand.
HTH.
David – Thanks for you contribution to this post.
You can schedule a Windows Job to execute the following PowerShell script to start the fmxdbc_listener if it’s not already started:
#############################################################
$fmListenerName = “fmxdbc_listener”;
$fmListenerExe = “C:\Program Files (x86)\FileMaker\FileMaker Server\Database Server\Extensions\xDBC Support\fmxdbc_listener.exe”;
$fmListenerProcess = Get-Process $fmListenerName -ErrorAction SilentlyContinue;
if ($fmListenerProcess -eq $Null)
{
Start-Process $fmListenerExe;
}
#############################################################
Another method, using WMI:
SELECT * FROM Win32_Process WHERE Caption = ‘fmxdbc_listener.exe’
I’ve been using this to query for the listener and restart if it’s down. In our case querying every 60s has no observable performance impact on the server.
Here’s a python script that uses `wimrm` to make a remote call to the filemaker server and restart the listener using `fmsadmin`: https://gist.github.com/douglas-larocca/4173d94676068b2d48a8532a3164b03f