Script engine loopt soms vast

[hans erik]

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? 

[menno]

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

[hans erik]

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 May 8, 2019 by hans erik

[menno]

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

[hans erik]

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).

[menno]

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.

 

[hans erik]

On 5/22/2019 at 11:47 AM, menno said:

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.

 

Aha! Dat zou de reden wel eens kunnen zijn.

Ik had de cachesize in FMS16 op 8000 MByte staan, maar ik had begrepen dat FMS17 die zelf optimaliseerde, ook al omdat die instelling uit de console verdwenen was.

Dat blijkt dus helemaal niet zo te zijn. Heb hem nu op 7000 staan (was 512MB!!). En FMS17 heeft de instelling van FMS16 natuurlijk niet overgenomen, want je doet een uninstall bij de upgrade....

Het aantal scriptsessies zal niet gauw de bottleneck zijn, er draaien eigenlijk nooit meer dan 4 scripts tegelijk en nooit asynchroon.

Ik kijk het zo even aan. Nu we het er toch over hebben: het aantal hostedfiles maakt toch niks uit? Ik bedoel: FMS reserveert geen extra geheugen als dat aantal op de default van 125 blijft staan.

Wat ik niet terug zie is het aantal dataAPI connecties. Of wordt dat gewoon bij de WebDIrect en FMP connecties geteld?

Dank!

HE

Edited May 24, 2019 by hans erik

[hans erik]

7 minutes ago, hans erik said:

Aha! Dat zou de reden wel eens kunnen zijn.

Ik had de cachesize in FMS16 op 8000 MByte staan, maar ik had begrepen dat FMS17 die zelf optimaliseerde, ook al omdat die instelling uit de console verdwenen was.

Dat blijkt dus helemaal niet zo te zijn. Heb hem nu op 7000 staan (was 512MB!!). En FMS17 heeft de instelling van FMS16 natuurlijk niet overgenomen, want je doet een uninstall bij de upgrade...

Wat ik dan wel héél merkwaardig vind, is dat FMS17 in de console niet eens de cachesize laat zien, terwijl dat toch een extreem belangrijke instelling is!

Het aantal scriptsessies zal niet gauw de bottleneck zijn, er draaien eigenlijk nooit meer dan 4 scripts tegelijk en nooit asynchroon.

Ik kijk het zo even aan. Nu we het er toch over hebben: het aantal hostedfiles maakt toch niks uit? Ik bedoel: FMS reserveert geen extra geheugen als dat aantal op de default van 125 blijft staan.

Wat ik niet terug zie is het aantal dataAPI connecties. Of wordt dat gewoon bij de WebDIrect en FMP connecties geteld?

Dank!

HE

 

[menno]

De DataAPI kan je alleen maar aan of uit zetten en de enige beperking is de capaciteit van de webserver en het verbruik van data. Verbruik van data is: de gegevens die je bij FMS opvraagt via de API (24GB per jaar / per user, die 2GB per maand is een onzin-getal, want je kan niet per maand afrekenen en je verbruik wordt per jaar gecheckt, niet per maand). Uploaden via de API is ongelimiteerd.

Container-data is van die 24GB uitgezonderd, dat kost je dus niks. De limiet kan over alle users op willekeurige wijze worden verdeeld en hoeft ook niet door een user van FM te worden gebruikt.

[hans erik]

Ik heb de cache nu alweer een paar dagen op 7000 MByte staan, maar het probleem met FMSE blijft zich voordoen.

Altijd op dezelfde plek: ik maak een PDF aan. Het laatste 'teken van leven' is vlak vóór 'Save records as PDF'. Er is dan eerst wel een plugin functie uitgevoerd, maar daarna volgen nog verschillende 'normale' scriptstappen voordat de logentry weggeschreven wordt. En het wegschrijven van de logentry is natuurlijk ook een 'gewone' scriptstap, met een commit.

Ik denk dat de plugin dus niet de boosdoener is, maar toch iets in die Save records as PDF.

 

[menno]

Wat staat er in de PDF? Wat voor afbeeldingen? Welke lettertypen? Helpt het als je de afbeeldingen van de lay-out weglaat?  Helpt het als je de gebruikte lettertypen vervangt voor Arial?

Hoe maak je de PDF? In één keer? Of die iedere keer een stuk aanhangen met append? Hoe groot is de PDF die je produceert?

Ik gebruik deze techniek namelijk zelf ook en heb er nog nooit problemen mee gehad. Alleen schrijf ik de PDF in één keer ipv aanmaken en vervolgens telkens wat aanhangen. Dus ik ben wel benieuwd naar wat er bij jou fout gaat.

[hans erik]

4 hours ago, menno said:

Wat staat er in de PDF? Wat voor afbeeldingen? Welke lettertypen? Helpt het als je de afbeeldingen van de lay-out weglaat?  Helpt het als je de gebruikte lettertypen vervangt voor Arial?

Alleen (juridische) tekst, met als enige graphic een PDF of JPG als achtergrond. Lettertype alleen Calibri of alleen Arial (dat laatste omdat sommige gebruikers problemen met Calibri ondervonden!). Alle tekst wordt via een theme geformatteerd. Geen vrije invoer, d.w.z. tekst die in velden geplakt wordt via een autoCalc van formatting gestripped. Maar dat is geen garantie voor bagger, helaas.

Ik maak wel heel veel gebruik van de 'sliding fields' optie: alles schuift naar boven toe op. Je hebt kleine alinea's en langere lappen tekst, en indents, tabs etc.

 

4 hours ago, menno said:

Hoe maak je de PDF? In één keer? Of die iedere keer een stuk aanhangen met append? Hoe groot is de PDF die je produceert?

Altijd in één script, maar wel meestal in twee stappen: een rapport en een bijlage, afhankelijk van de inhoud en opties. De PDF's worden eigenlijk nooit groter dan 350KByte, ook al omdat ik ervoor zorg dat achtergrond graphics beperkt blijven. Optioneel kan de inhoud tegen kopiëren beveiligd worden met een wachtwoord, dat de gebruiker overigens niet weet en ook niet zelf kan wijzigen.

4 hours ago, menno said:

Ik gebruik deze techniek namelijk zelf ook en heb er nog nooit problemen mee gehad. Alleen schrijf ik de PDF in één keer ipv aanmaken en vervolgens telkens wat aanhangen. Dus ik ben wel benieuwd naar wat er bij jou fout gaat.

Ik ook!! Ik denk toch aan een probleem in de PDF engine die FMI voor Windows heeft gebakken. Ik heb al eerder problemen gehad met gebruikers die Calibri gebruiken en vanaf een soort Citrix omgeving werken. Het probleem komt erop neer, dat regels grotendeels 'samenklonteren' in de eerste positie. Dus alle letters worden op de eerste positie geplaatst, een soort zwarte brij. En ik kan het in zoverre reproduceren, dat als ik de tekst uit een paar probleem alinea's naar de Mac client kopieer, het daar ook tot rommel leidt. Het zit dus bij dat probleem in de metrics van de karakters, die op dat citrix platform via het clipboard binnenkomen, het lijkt erop dat de PDF generator de karakterbreedte soms op nul zet, heel vreemd. Heb gedacht dat het aan de versie van Calibri ligt bij de client, maar als ik de PDF on server laat generen zou dat geen rol moeten spelen, maar het probleem bleek alleen met Arial op te lossen!

[hans erik]

Ik heb nu de aanmaak van de PDF maar weer naar de lokale WS gehaald en tot nu toe heeft de fout zich niet meer voorgedaan...

Ik denk dat het te maken heeft met het schrijven naar een bestaande PDF (append) eventueel in combinatie met een read-protect password.