9 Replies Latest reply on Jun 26, 2017 5:54 AM by wfgclapp

    (intermittent and false negative)  XML error: No memory at line 1

    wfgclapp

      I am (sometimes) getting this error when posting data into only two fields in a single record.

       

      Sometimes I get the error but the data was inserted into the fields anyway.

       

      I am using curl to PUT some json that is contained in a .txt file. The size of the file of json txt is around 4.8MB and is typically sent only once per day. The contents of the json vary slightly from day to day but is basically static.

       

      The destination file is hosted by FMS16 installed on an AWS server with Win2012R2 OS, with all updates for both Windows and FileMaker. This server is being used for development by me only and so has no other traffic besides what I am doing (more on this later).

       

      Here is a timeline:

      1. The above transmission is performed once each day in the morning. Except on Thursdays and Fridays when it is repeated a second time in the afternoon.

      2. The process will run successfully Monday-Thursday morning just fine. But it will fail with the "No memory at line 1" error on Thursday afternoon and then on every transmission attempt thereafter until I "do stuff" to the Windows server.

           a. By "do stuff", I mean that I haven't yet nailed down exactly what it is I do that finally allows the transmission to succeed. But it is some combination of restarting the FM service and/or rebooting the server and/or clearing the contents of the inbound text fields. I have tried all these things in various combinations and I'm embarrassed to say I have no idea what actually works. But after several attempts at these "fixes", it just "starts working." Yeah, I know.

      3. I have run this for 3 weeks now and each time it first fails on the Thursday afternoon run.

       

      Of note: in my various attempts to "clear the memory" or whatever it is I do that winds up making it work again, I have noticed at least a couple of times where I will get the "No memory" error but the data is actually sent successfully. That's part of what makes it difficult for me to tell exactly what it is I do that "fixes" the issue.

       

      Of note: I said earlier that the server has no traffic besides "what I am doing". There is one other thing I'm doing on the server that might be important here. Besides this single once-daily transmission, I also have a looping routine running 24-7 that sends data to the same hosted file via the same method (curl PUT of json data in a txt file). But none of this data goes to the table or layout for which my above transmission is failing. These transmissions are tiny compared to the once-daily (ie. typically 3k, at most 400k). But they are running all the time and I have experienced "ephemeral port exhaustion" because of it. On the Win Server I have reduced the TIME_WAIT on those ports to 45s down from 4m and that seems to have fixed the port exhaustion problem. And by the way, this TIME_WAIT change was made after I started seeing this "No memory" issue. But...I wonder if in some similar fashion I'm eating up memory all week and it coincidentally crashes each Thurs afternoon. That doesn't seem likely but who knows.

       

      I know of no major changes to anything that coincides with when this problem started. I haven't had this process in place long and the problem basically started with the creation of the process, so it's "been there all along".

       

      I have 16GB of RAM on the server and 4112MB reserved for FMS cache.

       

      I'm a newbie at using FileMaker's PHP so I'm hoping there's something obvious I don't have tuned right or some such. Maybe something in the php.ini file?

       

      And for now, I don't have the time to re-write for FM16s new XML API.

       

      Anyone have any thoughts? There is likely all kinds of important info I've failed to list here. Please ask.

       

      Thanks

        • 1. Re: (intermittent and false negative)  XML error: No memory at line 1
          mikebeargie

          "FM16s new XML API"

           

          You mean FM16's new REST API, since the CWP XML API has been around for a while. the new one is based on JSON though, not XML. I am assuming since you are using PUT that you are using the CWP XML API already (as opposed to the CWP PHP API).

           

          ~5mb is actually pretty big for a .txt file. Can you share a copy of your code that has your details scrubbed out?

           

          Also, these bug reports may be related:

          FileMaker Server PHP error -"XML error: No memory at line 1 (error )"

          Unchangeable 10MB Limit on PHP xml_parse means we can't get all our data from FM Publishing with one...

           

          So as you can see, there is known bug when FMS tries to return more than 10mb of information from a request.

           

          Sharing your source code here may allow us to identify somewhere that is causing a larger chunk of data to be transmit either on the PUT or in the response.

           

          My normal routine for sending files over CWP is via the PHP API using something like:

          -Upload file to web server /uploads/__UUIDpath___

          -CWP: Write a url of the file location to a record in filemaker referencing the above file path.

          -CWP: Tell filemaker to run a script that inserts that file into a container field corresponding to the UUID.

          -FMS: Scheduled script that checks for failed insert operations on a daily basis and attempts to fix automatically.

          -Win Scheduled Task: Clear the uploads folder of files older than three days every evening to keep the folder tidy.

           

          I'd also recommend you see if you can try "chunking" or streaming the file. PHP has a number of streaming options that allow you to break up a file into smaller chunks to work with. Most web operations perform better as a smaller transaction run many times, versus a larger action run one time.

          • 2. Re: (intermittent and false negative)  XML error: No memory at line 1
            wfgclapp

            Thanks for the response Mike.

             

            Here's my cURL request:

             

            curl -H "Content-Type: application/json" -X PUT -d "@/...pathAndFilenameOfTxtFileContainingJsonData" "http://USER:PASS@SITE/RESTfm/FILENAME/layout/LAYOUTNAME/id%3D%3D%3D1.json?RFMelsePOST" -o pathAndFilenameOfFileForResult

             

            i'm using Goya's RESTfm, which I've been very pleased with.

             

            The json data contains only two data/value pairs. One is simply the id field, id::1 in case the record doesn't exist and the second is a text field called receivedTxt whose value is a Base64 encoded Gzip file (so, a string of encoded txt). The zip file is the tab delimited file I want to ultimately import into my FileMaker table. (This import is handled by an FMS scheduled script and works fine once I can successfully populate the receivedTxt field.

             

            And like I said, all of this actually works (except sometimes it doesn't).   ;-)

             

            If I'm exceeding the 10MB limit then I'm not sure where. I wonder...the value I'm inserting in the text field is around 4.8MB right? If the field is not clear when I'm inserting new text, does FileMaker have to do something like keep the original 4.8MB in cache while inserting the new text? If the size of the old text and new text together is greater than 10MB would that possibly have an effect? I"m grasping at straws here.

             

            Thanks.

            • 3. Re: (intermittent and false negative)  XML error: No memory at line 1
              mikebeargie

              I'm not an expert here by any means since I don't really attempt a full on insert of that much data anywhere in my solutions (rather chunking the results like I noted above, or doing a "passthrough" upload).

               

              RestFM is honestly just a wrapper for XML CWP, so possibly something is erroring out in that process. I agree it's a great tool, but it still is just a wrapper and may have shortcomings.

               

              CWP has a bad habit of including the entire record's content sometimes as part of its "response" to the original command. So what I was thinking was that your upload + the response + translation through RestFM is somehow going over the limit.

               

              One thing I didn't ask before, when this freeze up happens, are you seeing a lot of "hung" CWP sessions in your FMS admin console? Since the symptom is works...works...works...fails with a relative consistency, it seems like the cache is spooling up somehow to the point of failure (definitely suspicious).

               

              How about enabling topcallstats logging and seeing if that nets any results. FM Perception has a feature to "translate" the topcallstats log, and they have a trial if needed.

              2 of 2 people found this helpful
              • 4. Re: (intermittent and false negative)  XML error: No memory at line 1
                wfgclapp

                Mike Beargie wrote:

                 

                I'm not an expert here by any means since I don't really attempt a full on insert of that much data anywhere in my solutions (rather chunking the results like I noted above, or doing a "passthrough" upload).

                 

                RestFM is honestly just a wrapper for XML CWP, so possibly something is erroring out in that process. I agree it's a great tool, but it still is just a wrapper and may have shortcomings.

                 

                CWP has a bad habit of including the entire record's content sometimes as part of its "response" to the original command. So what I was thinking was that your upload + the response + translation through RestFM is somehow going over the limit.

                 

                One thing I didn't ask before, when this freeze up happens, are you seeing a lot of "hung" CWP sessions in your FMS admin console? Since the symptom is works...works...works...fails with a relative consistency, it seems like the cache is spooling up somehow to the point of failure (definitely suspicious).

                 

                How about enabling topcallstats logging and seeing if that nets any results. FM Perception has a feature to "translate" the topcallstats log, and they have a trial if needed.

                Good thoughts of places to look.

                 

                And I'll use top call logging. I already have FM Perception so I'll definitely use that. It definitely feels like a caching issue.

                 

                Thanks Mike!

                • 5. Re: (intermittent and false negative)  XML error: No memory at line 1
                  designdb

                  Let me know if the Top Call Log analysis in FMPerception helps.  I'm always interested in the experiences of people using my software (good or bad).

                  • 6. Re: (intermittent and false negative)  XML error: No memory at line 1
                    wfgclapp

                    designdb wrote:

                     

                    Let me know if the Top Call Log analysis in FMPerception helps. I'm always interested in the experiences of people using my software (good or bad).

                    Thanks David. So, I examined the top call log with FMPerception and I found my problem is definitely that I'm exceeding the 10MB limit on total Bytes In. But I don't understand why, since what I'm uploading is no bigger than 4.8MB. Obviously something I don't understand about CWP. Or RESTfm. Or both.

                     

                    Below is a screenshot of the FMPerception analysis of my request. I don't know what "Download With Lock" is, nor why there are 5 instances of it. I understand that "Upload List" is my data upload, but I don't understand why there are 10 instances, nor why the total of all the instances adds up to at least twice what I'm sending up.

                     

                    Any insight would be appreciated.

                     

                    Oh and by the way, this transmission generated the "No memory" result, BUT, the actual transmission of data succeeded.

                     

                    • 7. Re: (intermittent and false negative)  XML error: No memory at line 1
                      designdb

                      So, let me first say that there is a lot we don't know about exactly what and how the server logs various actions to the top call stats.

                       

                      4.8 MB is 5,033,164 bytes, which maps pretty closely to the size of what the Download With Lock is reflecting (once you allow a little fudge room for network overhead).  I can not tell you why it's pushing (maybe) a copy of what you just uploaded out through the network...  Perhaps it's a thing where the "layout" that you're referencing though the API now contains that data, and it has to update the record... I'm just guessing.

                       

                      I can't speak to why it is uploading about 2X your data size.  Even accounting for some sort of encoding magic, I don't think it would get that big.

                       

                      Unfortunately, those particular FileMaker APIs are not within my areas of experience.  Mike Beargie knows more about that stuff than I will ever know.

                       

                      I'm hoping to get more info about the behind-the-scenes details of the Top Call Stats Log at DevCon.

                      • 8. Re: (intermittent and false negative)  XML error: No memory at line 1
                        wfgclapp

                        designdb wrote:

                         

                        So, let me first say that there is a lot we don't know about exactly what and how the server logs various actions to the top call stats.

                         

                        4.8 MB is 5,033,164 bytes, which maps pretty closely to the size of what the Download With Lock is reflecting (once you allow a little fudge room for network overhead). I can not tell you why it's pushing (maybe) a copy of what you just uploaded out through the network... Perhaps it's a thing where the "layout" that you're referencing though the API now contains that data, and it has to update the record... I'm just guessing.

                         

                        I can't speak to why it is uploading about 2X your data size. Even accounting for some sort of encoding magic, I don't think it would get that big.

                         

                        Unfortunately, those particular FileMaker APIs are not within my areas of experience. Mike Beargie knows more about that stuff than I will ever know.

                         

                        I'm hoping to get more info about the behind-the-scenes details of the Top Call Stats Log at DevCon.

                         

                        No sweat, thanks. I'll be digging for answers too. Will also keep poking around with it and if I learn anything worthwhile I'll come back and post.

                        • 9. Re: (intermittent and false negative)  XML error: No memory at line 1
                          wfgclapp

                          Issue Update:

                           

                          I believe I have found a way to avoid my error and still send my file in its entirety.

                           

                          Even though my http request is only dealing with two fields on my "inbound" layout, there is clearly some transmission overhead coming from all the other fields on that layout. I removed all fields but the two I am updating and I have yet to see a failure. Interestingly, I still see over 10MB (total) in and out in my top call stats.

                           

                          The other fields on my layout were the decoded and unzipped version of my inbound contents, so at least several times greater in size than my original PUT data.

                           

                          There is still a lot I'm confused about with the Top Call Stats and hope FileMaker can clear up at some point. Also a lot about CWP I need to learn too.

                           

                          Thanks to everyone for your responses!