Jump to content
  • 0
Sign in to follow this  
hans erik

Script engine loopt soms vast

Question

Ik heb een FMdatabase (Windows Server 2016) onlangs overgezet van FMS 16 naar FMS 17.0.3.324  Sinds die tijd loopt de script engine van tijd tot tijd vast.

- ik gebruik geen Scheduled scripts, alleen PSoS.

- het gaat om 2 scripts. Eén lang complex script dat veel subscripts aanroept maar nooit in een loop verstrikt kan raken. Dat script loopt ca 6 seconden op de server. Een ander script maakt een PDF aan, schrijft soms meerdere rapporten naar dezelfde PDF, en maakt gebruik van Base Elements 4.0.3 om de PDF uit de documentsfolder in een containerveld te importeren (daarna wordt de PDF verwijderd om de zaak opgeruimd te houden).

- de scripts hebben altijd als voorwaarde 'wait for completion'. 

Als de FMSE vastloopt, resulteert dat in een strandballetje. Een volgend script wordt gestart, maar komt nooit tot een einde.

Heb al op de FM community gekeken, en ik ben niet de enige. Maar waar het precies door veroorzaakt wordt is me niet duidelijk. Onder FMS16 kwam dit nooit voor. Op de MacOS server lijkt het ook niet voor te komen.

Ik heb op verschillende plaatsen in de scripts logstappen tussengevoegd met een commit, zodat ik kan zien wat er uitgevoerd is en wat niet. Het lijkt er niet op dat het aan de plugin ligt, die doet keurig zijn werk, maar  eerder dat van tijd tot tijd een PSoS script niet 'afgemeld' wordt en voor de server dus blijft 'hangen'. Als dat 25 keer gebeurt, worden alle volgende scripts 'pending'. Tussen twee 'crashes' worden tussen de 100 en 160 PSoS scripts uitgevoerd, maar elk script kan dus meerdere subscripts aanroepen.

De reset doe ik in zo'n geval via de CLI, fmsadmin STOP FMSE en fmsadmin START FMSE. De gebruikers die op een script zitten te wachten krijgen dan een melding dat het script niet kon uitgevoerd. In het event log zie ik echter geen rare dingen gebeuren op het moment van vastlopen, vandaar dat ik mijn eigen logging toegevoegd heb.

NB als je direct na de restart van de FMSE het script opnieuw start krijg je een foutmelding dat het aantal gelijktijdige script (25) overschreden is. Na een minuut ofzo accepteert ie weer nieuwe scripts.

Iemand soortgelijke ervaringen? 

Share this post


Link to post

5 answers to this question

Recommended Posts

  • 0

Dag Hans Erik,

ik loop ook wel eens tegen dat probleem aan en ben er ook nog niet achter waarom dit gebeurt.

 

Je kan echter het gebruik van een plug-in helemaal overboord gooien als de volgende werkwijze gebruikt op de server:

Eerst de variabelen declareren:

Let ( [ 
	$fileame = "filename.pdf" ; 
	$create = "filewin:" & Get ( TemporaryPath ) & $filename ; 
	$insert = Substitute ( $create ; [ "filewin:/" ; "file:///" ] ) 
] ; 
	"" 
)

Dan sla je de pdf op met (deze stap gebruik je denk ik al):

Save Records as PDF [No dialog; "$create"; Records being browsed]

en vervolgens vul je het bestand aan met (deze stap gebruik je denk ik ook al):

Save Records as PDF [No dialog; Append; "$create"; Records being browsed]

Daarna het bestand in de database zetten met insert from URL:

Insert from URL [Select; No dialog; MyTable::Container; $insert]

Als het script stopt is de gebruiker ook weg uit de database en wordt de inhoud van de temp-directory automatisch geleegd. Iedere psos-sessie heeft een eigen temp-directory, dus ze zitten elkaar nooit in de weg. Je hoeft zelf nooit iets op te ruimen en dus kan je de plug-in op de server opruimen.

HTH, Menno

Share this post


Link to post
  • 0
Posted (edited)

Dank voor je suggestie.

Dat van die insert from URL had ik niet aan gedacht, ga ik zeker proberen. 

Ik gebruik de plugin ook om HTML mail te versturen en omdat het uiteindelijk ook vanuit WebDirect moet gaan werken vrees ik dat ik hem toch nodig zal hebben. Maar ook: het is een raar probleem omdat ik vermoed dat bepaalde scriptstappen de queue in de war sturen. Het lastige is alleen dat nergens uit te lezen valt wat de werkelijke staat van die queue is. Wim de Corte suggereert dat het een performance probleem is (16GByte RAM?). 

Ik maak een logentry op bepaalde plaatsen in de scripts, ondermeer nadat de plugin wordt aangeroepen. Is dat dan succesvol dan zie je dat in de log. En elke PSoS registreert een start en een stop. Ontbreekt de stop dan weet je welk script en gebruiker de eerste is die 'hangt'. En je weet welke scriptstap als laatste succesvol was. Het probleem lijkt nu uit de Save Records as PDF te komen...

Dus niet uit de plugin, maar zeker weet je dat natuurlijk nooit.

NB sommige gebruikers draaien FMP vanaf een soort Cytrix achtige omgeving. De PDF heb ik naar PSoS verplaatst omdat het gebruik van Calibri op die werkstations de PDf ondersteboven gooide. Heel vreemd: de content bevatte tekens met afwijkende metrics denk ik, en dat resulteert in een volstrekt door de war gegooide PDF! Dat probleem bleef op de server ook terugkomen, en verdween pas toen ik de rapporten in Arial opmaakte(!), Maar het zou dus in theorie aan de inhoud van de PDF kunnen liggen?

Edited by hans erik

Share this post


Link to post
  • 0

Ik zit nog eens naar jouw eerste verhaal te kijken en zie dat het maximum aantal scrip-sessies nog op de standaard 25 staat. Ik weet niet hoeveel gebruikers je hebt en hoeveel gelijktijdige PSoS-sessies je zal hebben, maar bij bijvoorbeeld 25 gebruikers is een max van 25 wel enigszins laag.

Helaas heeft FMI in haar oneindige wijsheid besloten de UI uit te kleden en de basisinstellingen zoals het maximum aantal  script-sessies alleen nog met de commandline in te laten stellen. 

Gebruik: 

fmsadmin set serverconfig scriptsessions=<aantal> -u<username> -p<password>

Voor <aantal> kan je getal tussen 0-500 invullen

Share this post


Link to post
  • 0

Zal ik ook even naar kijken. Heb inmiddels de laatste upgrade geïnstalleerd maar het probleem bljift zich voordoen, en het treedt altijd op bij het aanmaken van een PDF (op de server).

Dus ik denk dat daar een fout in zit.

Ga nu het PDF script naar lokaal halen en kijk of het over is.

Wat betreft het aantal sessies: wat bedoelt FMI precies met een sessie? Stel dat je een script on Server uitvoert en dat script roept 7 subscripts aan, zijn dat dan 8 sessies of is het er 1?

Het gaat allemaal zo snel dat je in de console die teller echt niet ziet verspringen, en de log is zoals gebruikelijk vrij nietszeggend. Mijn gevoel zegt me dat het 1 sessie is (ik heb geen scripts die in een soort oneindige loop terecht kunnen komen, de scriptstack wordt ook nooit langer dan 4).

Share this post


Link to post
  • 0

Ik maak op FMServer ook PDF's en tegelijkertijd UBL-bestanden (xml/xslt-export) voor mijn uitgaande facturen en heb daarbij nog nooit een "vastloper" gehad. Ook bij het uitvoeren van een batch van een paar honderd stuks was er geen enkel probleem. Het produceren van de bestanden en ze uploaden in de database werkt dus op zich goed. Mogelijk dat je resources tekort komt .... wat krijg je als antwoord wanneer het volgende commando uitvoert op de commandline?

fmsadmin get serverconfig -u<username> -p<password>

Het antwoord zou ongeveer er zo uit moeten zien:

BackupInterval = 5 [default: 5, range: 1-99]
CacheSize = 4096 [default: 512, range: 64-1048576]
HostedFiles = 125 [default: 125, range: 1-125]
LogSize = 40 [default: 40, range: 1-1000]
ProConnections = 50 [default: 250, range: 0-2000]
ScriptSessions = 100 [default: 25, range: 0-500]
SecureFilesOnly = true [default: true]
StatsInterval = 30 [default: 30, range: 1-300]

Met name de CacheSize en de ScriptSessions zijn belangrijk om goed in te stellen. FMS gaat niet vanzelf het beschikbare geheugen gebruiken, als je bijvoorbeeld 16GB werkgeheugen hebt en je wilt optimaal/maximaal gebruik kunnen maken van de Cache, dan moet je zelf 8GB (8192) instellen, de helft van wat beschikbaar is. De andere helft is dan voor je webserver om webdirect, cwp en de dataApi te draaien.

Instellen kan je met het commando:

fmsadmin set serverconfig <parameternaam>=<waarde> -u<user> -p<password>

Je kan in één commando meerdere <parameternaam>=<waarde> zetten door ze simpel met een spatie te scheiden. De parameternamen mag gewoon lowercase meegeven.

Hoeveel subscripts je aanroept maakt niet uit, er is er altijd maar 1 die daadwerkelijk iets uitvoert en dat is degene die op dat moment aan het einde van de ketting zit. 

Het wordt een ander verhaal wanneer je de PSoS asynchroon laat uitvoeren (vinkje "wachten op uitvoering" uitzetten), want dan kan je meerdere PSoS-sessie naast elkaar laten draaien vanaf een client. Iedere afzonderlijke PSoS-call geldt als een script-sessie en script-schedules opde server vallen daar ook onder.

 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  
×
×
  • Create New...