Jump to content

Jonathan Perel

Members
  • Content Count

    29
  • Joined

  • Last visited

  • Days Won

    1

Jonathan Perel last won the day on February 3 2016

Jonathan Perel had the most liked content!

Community Reputation

1 Neutral

About Jonathan Perel

  • Rank
    newbie

Profile Information

  • Gender
    Male
  • Location
    San Francisco

Recent Profile Visitors

4,008 profile views
  1. There could be a memory leak somewhere not related to the JARs. I'd do a SMIsRegistered type test before registering the SM modules and skip registering if they're already loaded. JP
  2. Its probably the "max files" issue. I thought 360works would have fixed it on the latest release, but it still happens. Each time a server side script runs and initializes ScriptMaster, ScriptMaster reloads JARs even when they are already loaded (there may also be a memory issue going on, which is why increasing the heap size can help). ScriptMaster should either purge open JARs when exiting a server side execution, or it should check for open JARS and not reload them. Here's the original post:I use this command-line command to check how many JAR files are opened. If the number goes up each time the script runs then you've got the issue. lsof -p `pgrep fmsased` | grep jar | wc -1Omit the "| wc -l" to see if there are multiple copies of the same jars open. My solution was to create a SMIsRegistered module that returns "true", and only initialize ScriptMaster if that script doesn't return true.
  3. You can have a disabled server side script which can run "fmsadmin -y restart fmse", and you can run it manually on the server if you make changes to any of your ScriptMaster modules. That way the next time your server side scheduled (or perform on server) scripts run, then they'll initialize ScriptMaster JARs and Modules when the "SMIsRegistered" call fails. (or change the SMIsRegistered function to return a serial number, which you check for in your initialization script. Increment it on your initialization script check and in the ScriptMaster module everytime you make a change.)
  4. My temporary fix: I create a ScriptMaster module called SMIsRegistered which returns "true". Then in my initialization code, I try to call it and skip initializing ScriptMaster if it returns "true. SMIsRegistered return ( "true" ); This should keep ScriptMaster from re-initializing when running on Server Side Scripting. JP
  5. BTW: I've sent my logs to 360works and they're going to look at this issue.
  6. Hi John, I can confirm that there's a problem with SMGetRegisteredModules and SMGetLoadedJars. I tried the following: 1. restarting the FMSE 2. registering ScriptMaster with a scheduled script A 3. testing for SMGetRegisteredModules and SMGetLoadedJars with another scheduled script B 4. trying to run ScriptMaster modules with scheduled script B SMGetLoadedJars and SMGetRegisteredModules do not return anything, however, all ScriptMaster modules are actually loaded and working. So something internal to ScriptMaster isn't keeping track of loaded JARS and modules across scheduled script (and perform on server) calls, and so you can end up loading JARs and Modules over and over if you rely on SMGetLoadedJars and SMGetRegisteredModules to tell you what's loaded. JP
  7. I created my own event logging database which logs events I generate throughout my code. This screenshot shows two back-to-back scheduled executions of a script "server side - run scripts". I have script "util - Plugin initialize ScriptMaster" call the "Startup" script in the ScriptMaster file. Before that call I check to see if there are any loaded JARs or registered modules, which I repeat at the end of the Scriptmaster initialization. I took your advice and am skipping reloading previously loaded JARs during the ScriptMaster module registration. You'll see that case where it says "Skipping loaded jar: ..." The thing to note is that the second time the scheduled script runs, there are no JARs loaded and there are no modules registered. So it looks like each time a scheduled script runs server side (or a "perform script on server" script runs), it runs in a new session (with a clean environment of global variables, plugins, JARs, etc). Â Cheers, JP Â Â
  8. Hey John, I was under the impression that in the Server Side Scripting, a new client session is created every time a scheduled script or a "perform on server" is executed (as each session would have its own global variables). In looking at my logs, I'm seeing that you're correct that the jars (and even the registered ScriptMaster modules) are maintained in the Server Side environment across scheduled script calls. I'll try your suggestion of only loading jars if they aren't loaded already. It still seems like a bug to me that ScriptMaster doesn't release the file handles to when you reload them, or even when you execute the SMReset function. Anyways... I just re-checked my logs and it looks like each time a scheduled server side script is run, there are no loaded jars or registered modules - even if a previous scheduled server side script loaded jars and registered modules. This means that I do have to load jars and register modules every time a scheduled script (or a perform on server script) runs server side, and I will run into the unreleased file handles issue. I made a change in the Load jars for modules("all") function so it checks SMGetLoadedJars to the jar its about to load. This does save me from loading jars mutliple times in a single session, but it doesn't resolve the file handles left open across sessions. Thanks for the info! JP
  9. Hi Folks, I'm wondering if anyone out there is having stability issues when running server side scripts which use ScriptMaster on FileMaker 13 Server. Everything seems to run well for a while, but after running for a while, scripts running on FileMaker Server Side start failing. It appears that every time a script using ScriptMaster runs server side, the appopriate JAR files are loaded, but when the script is done those file handles are never released. Eventually, the number of open file handles gets to the maximum allowed for a user/process and the fmsased process can no longer open any files. This means that ScriptMaster can no longer load (even FileMaker functions such as server side sending mail via SMTP won't work), until you reset the server side process via: fmsadmin restart fmse You can keep track of the ever growing list of ScriptMaster JAR handles via the following command: lsof | grep ScriptMaster | grep jar | wc -l So has anyone out there seen this issue or found a work around? I never saw this issue with FileMaker 12 Server, so I'm not sure if its a FM Server issue or a ScriptMaster issue. I have tried adding an "SMReset" prior to the initialization of ScriptMaster, and when my script is about to end. It does not seem to release the JARs. I'm going to try having my script check the number of open files for the fmsaed process: lsof -p `pgrep fmsased` | wc -1 and when that number gets too large ( say 100,000) restart the fmse engine with: fmsadmin -y restart fmse Cheers, JP
  10. I use the Actual Open Source ODBC connector to allow filemaker to connect to the MySQL databases. Exposes the MySQL as external sources in FMP. http://www.actualtech.com JP
  11. Its totally possible to do that. However, you have to make sure that the "fmserver" user has a login shell selected. I think by default the user's login shell is set to none. To set the login shell, use workgroup manager or the User pref pane (control-click on the user name to get the advanced options menu). I'd recommend using the bash shell. A fun trick is to perform commands on other servers directly through SSH. Create a private and public openssl key, put the public key on the server you want to send commands to (in the user's ~/.ssh/authorized_keys file) and then you use the private key establish the connection from your FileMaker script. Here's the link to the ScriptMaster script to send SSH commands directly from FMP. http://fmforums.com/forum/topic/90891-executing-ssh-commands/ Just provide a hostname, user name on the host, private key, and a shell command, and it uses the JP
  12. BTW: Requires commons.io and commons.lang JARs as well...
  13. Here's the script: http://fmforums.com/forum/topic/88305-exporting-container-field-to-file/
  14. I wrote a ScriptMaster script to export container fields to files. Works great server side. Otherwise, i think that the BaseElements plugin can do this too. Here's the link: http://fmforums.com/forum/topic/88305-exporting-container-field-to-file/ JP
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.