Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

random page load and PDF errors

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • eswindhauser
    replied
    Originally posted by mikeallenbrown View Post
    Only took three years but at least it's resolved.
    Luckily no - it was resolved a long time ago but I just realized I never posted a follow up.

    Leave a comment:


  • mikeallenbrown
    replied
    Only took three years but at least it's resolved.

    Leave a comment:


  • eswindhauser
    replied
    Update - it appears this issue was resolved by increasing RAM and going to a load balancer. Thank you ZebraHost for helping us out!

    Leave a comment:


  • RichCPT
    replied
    Re: random page load and PDF errors

    Jeff,
    I am just proposing the question that perhaps only first-time requests to the server be given a second chance, if they fail. Any request that is on its second chance would not be given another chance.

    P.S. requests can be given a timeout value, so the client-side javascript can do something if it never receives a response. Although, in my client-side log of XMLHttpRequest() function/object callbacks it appears that may not be the case, but it could be because AA does not set a timeout value for many of the requests its makes of the server or the users simply closed out (or killed) the browser before my logging code detected the final callback.
    Last edited by RichCPT; 06-27-2018, 01:01 PM.

    Leave a comment:


  • jgrannis
    replied
    Re: random page load and PDF errors

    It would be a nightmare if the AA javascript was coded to automatically continue to send requests just because the server did not respond (as it seems to be the case in the original post). It is bad enough that someone at Alpha decided to give a secondChance to 408 responses. Of course if you were receiving the status code 408, it would just mean that the client did indeed receive a message back from server but that status code does not mean that there was any error (it just is saying that it is closing a connection that it thinks you no longer need) and doesn't seem to be related to your issue in any way. Not even sure why the status 408 was brought up as I was under the impression that the client isn't getting any response from the server.

    Eric, do you always get no response headers back for those "(failed)" and "(cancelled)" cases?

    Have you looked into creating a "Failed Request Tracing" rule in the IIS Manager for your website/application? It can trace a lot about what is going on on the server side. For instance, you will definitely see if the web server created a response to send back to the client and that the client just simply never received.

    Leave a comment:


  • Pat Bremkamp
    replied
    Re: random page load and PDF errors

    Rich, I agree that the problem is probably the time it takes to create the pdf. As above, the solution might be the sleep() statement. I would make the simple change to

    filename = report.saveas("PFC_SC@[PathAlias.ADB_Path]\finance_agreement.set","pdf",filter,order,filename,.f.,pSet)
    sleep(3)
    filename2 = report.saveas("PFC_Instructions_NON_WC@[PathAlias.ADB_Path]\Finance_Agreement.set","pdf",filter,order,filename2,.f.,pSet)
    sleep(3)
    filename3 = report.saveas("PFC_PaymentForm@[PathAlias.ADB_Path]\Finance_Agreement.set","pdf",filter,order,filename3,.f.,pSet)
    sleep(3)

    Also, pdf_append_list is much faster than several pdf_append statements, so
    filelist = <<%txt%
    filename
    filename2
    filename3
    %txt%
    pdf_append_list(filelist,filename)

    If that solves the problem, then you can experiment with reducing the sleep time.

    Leave a comment:


  • RichCPT
    replied
    Re: random page load and PDF errors

    I found an option under IIS WAS, Session State, that says "Regenerate expired session ID". Maybe under IIS a session can be automatically renewed and that could be the reason for status error 408 leading to a second try of submitting the request to the server in the XMLHttpRequest function/object's "onStateChange" event. But I don't get how that would work.

    Leave a comment:


  • eswindhauser
    replied
    Re: random page load and PDF errors

    RichCPT - I agree about having to rewrite code on every page to alleviate this issue... we have over 1000 A5W and UX/Grid/Dialogs.... it would take us hundreds of hours to place code on every one of those pages... that is if I can even grasp the concept of what I need to do on each page to catch this error and refresh or ask the user to refresh (which is really crappy for an enterprise program). Maybe I need to send this up to Selwyn as a bug report? This cannot be acceptable to roll out to a commercial website/database.

    Leave a comment:


  • RichCPT
    replied
    Re: random page load and PDF errors

    Originally posted by RichCPT View Post
    BTW, the calls that run through the JS AA library function/object "$a.simple" are coded in the library to automatically send the request one more time to the server when they fail.
    I left out an important detail on the above quote: The request will be resent a second time only if the error status is 408 - "The server timed out waiting for the request."

    So, if this 408 error is really something returned by the server, as the Mozilla and Microsoft documentation seems to be saying, then Alpha Server or IIS is the one that decided to return that error code. I would think it means the web server has decided the user has been idle too long (timed-out).

    If the user's session has timed-out it seems to me that it does no good to try the request again, the server has already decided the user has been idle for too long.

    It could be that 408 means something else, like the server got tired of waiting for the response to be built by the process procedure building the response on the server.

    What ever error 408 really means, I suspect it is very rare and the automatic retry that it triggers is pretty much useless.

    Maybe all XMLHttpRequest (ajax) calls that fail should be given a second chance to run. The ajax calls that fail to get a response within a specified time period could be a little tricky - as perhaps the user should be given a message and a choice between trying again or aborting. That is what Lee said he does at the application. But, I cannot image having to go through the entire application and setting up the "Ajax failed JavaScript" property. Especially, since one never knows what parts of AA have that option.

    I think something has to be done at the very low level in the JavaScript library to help alleviate these problems. Even if the problem occurs only a small percentage of the time, that is reason enough for customers of a commercially marketed application to find another product.

    I have two windows desktop applications that access ISAM database servers across the Internet using TCP/IP. These apps do the same things that I'm trying to do with this AlphaAnywhere web application. But the users practically never have to re-submit requests to open forms or save records. These apps just work flawlessly across TCP/IP and they are very fast, despite not have a SQL database on the server! A small data server engine runs on the server as it services request to read/write data to ISAM files on the server.

    Leave a comment:


  • eswindhauser
    replied
    Re: random page load and PDF errors

    Ivasic - thank you. So do you simply write a javascript to display an error window instructing the user to refresh the page or can the javascript actually refresh it directly?

    Leave a comment:


  • lvasic
    replied
    Re: random page load and PDF errors

    ScreenCapture.PNG

    Leave a comment:


  • RichCPT
    replied
    Re: random page load and PDF errors

    Lee, same type of problems under IIS ! ? -- I thought that fixed these things.

    Eric, are you running under Alpha IIS ?

    If so, I wonder if the AA worker process is crashing on these requests and IIS is restarting it and since session state is persisted in the SQL DB and not in memory (if using the session state storage method that Terry Smith demonstrated) that IIS and AA is able to continue on with repeated request from the user without having the user log back in?

    Have you looked in the Windows logs and any logs AA IIS might be making to see if anything is showing up in the server logs?

    BTW, the calls that run through the JS AA library function/object "$a.simple" are coded in the library to automatically send the request one more time to the server when they fail. It would be nice to find out if any of the calls that are failing in your app are going through that function or not.

    I have only really looked at opening Grids and UX in a tabbedUI and processing of the save event. I have not looked at opening a5w pages or reports like you mentioned. Those probably go through a different mechanism. Nor, have I looked at what happens when the HTML refers to images, there's probably no way to track downloading of those like I do with the download of the Grid and UX component and submitting their data.
    Last edited by RichCPT; 06-21-2018, 04:21 PM.

    Leave a comment:


  • eswindhauser
    replied
    Re: random page load and PDF errors

    Ivasic - can you help direct me to the "Ajax failed JavaScript" you are referring to? I am not familiar with this.

    Leave a comment:


  • lvasic
    replied
    Re: random page load and PDF errors

    Rich,
    Thanks for all the detail. I've been using IIS for a while now and I'm still having the problems. It seems like after I got a bigger server box I had more timing issues. I started using the "Ajax failed Javascript" code hook and at least it gives the users some feedback so they can just click again to get it going again.

    Leave a comment:


  • RichCPT
    replied
    Re: random page load and PDF errors

    Yep, I have spent a lot of time trying to track down why the AA server seems to occasionally not respond. I don't know if it is because the user's request never makes it to the AA server or the AA server fails to respond or the response just never makes it back to the user.

    I'm in the process of having Zebrahost move us to a new facility and set us up without a load balancer on the traditional AA server. I've heard that load balancers can be a source of many problems.

    I built a client-side Ajax Event Tracking Log (AETL) that records all browser send and receive events that go through the "$a.simple" Ajax XMLHttpRequest object wrapper. There are a couple of other low level Ajax object wrappers that I do not bother logging. From the log I can see users are having troubles (failed response from server, server requests taking too long and events that never complete), but just not reporting them to me.

    I also discovered that the AA JS library is inconsistent with handling of detected errors. I have altered the JS library to display an error message when it fails to load a UX or Grid into the tabbedUI. Without the change the user just gets a spinning icon or blank tab when the main call for loading the grid or ux fails. There are secondary Ajax calls that take place when loading a Grid/UX. Displaying error messages for those events can be difficult.
    When we get moved to new facility (with no Load balancer, Solid State hard drives and 3x as much RAM) I will see if Ajax send/receive problems are diminished.

    After that, the next step is to see about converting to IIS AA. I hear that works better, or is at least better at covering up errors.

    Leave a comment:

Working...
X