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

Successful 6 Instances of WAS

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #91
    Re: Successful 6 Instances of WAS

    another 2 stupid ideas

    1.
    Assign one server to do all the reporting by pointing to it in the url, the other WASes would reduce the workload on the application


    2.
    create a table that "ques" the report requests so they get printed one at a time and wont fier the next report until the last one is marked as done.
    Of course if 10 users want to print a report at the same time the last one who request the report will have to wait for the other 9 before he gests his request. which beats the idea of having more than one WAS but you still get better performance in the applicationt itself aside from reporting
    Cheers
    Mauricio

    Comment


      #92
      Re: Successful 6 Instances of WAS

      Wow, I am sitting here upsizing my grids so that they will connect to MS SQL so that I can have an enterprise app with auditing tables. I thought everything would be a done deal if I invested in the correct servers and put forth the correct effort. This is long, repetitive and honestly painful work (135 grids). There are several necessary reports in my app that will be printed by hundreds of people monthly (Beta only) when I go live. It is entirely inappropriate to constantly look for work-a-rounds. Now I read that professional services are needed for printing reports, and through a desktop app none-the-less. How am I to be competitive with other software apps that have no such requirement? Yes, I am angry. But I think being angry is also being honest. I respect Alpha greatly, but we should all be informed of whatever limitations exist before starting a project. My apologies if I have been too forward. My bad.

      Comment


        #93
        Re: Successful 6 Instances of WAS

        Mauricio,

        You win for the most active brainstormer.

        #1 is what I asked about, but if the driver doesn't create a queue, won't it have the same issues regardless of how many places (IPs) the print jobs come from?

        Comment


          #94
          Re: Successful 6 Instances of WAS

          This queue idea is exactly what Alpha has created however I would have thought that if it was possible to have on the web they would have done it there and not through the desktop app.
          Chad Brown

          Comment


            #95
            Re: Successful 6 Instances of WAS

            Originally posted by koga101 View Post
            Yes, I am angry. But I think being angry is also being honest. I respect Alpha greatly, but we should all be informed of whatever limitations exist before starting a project. My apologies if I have been too forward. My bad.
            Well said.

            I do want to clarify that this is not happening when using one instance of WAS alpha has made the Amyuni work well and seem to queue items properly and print fine. Since I have changed to multiple servers this problem has gone away.
            Last edited by chadbrown; 10-06-2010, 07:59 AM.
            Chad Brown

            Comment


              #96
              Re: Successful 6 Instances of WAS

              Originally posted by koga101 View Post
              Wow, I am sitting here upsizing my grids so that they will connect to MS SQL so that I can have an enterprise app with auditing tables. I thought everything would be a done deal if I invested in the correct servers and put forth the correct effort. This is long, repetitive and honestly painful work (135 grids). There are several necessary reports in my app that will be printed by hundreds of people monthly (Beta only) when I go live. It is entirely inappropriate to constantly look for work-a-rounds. Now I read that professional services are needed for printing reports, and through a desktop app none-the-less. How am I to be competitive with other software apps that have no such requirement? Yes, I am angry. But I think being angry is also being honest. I respect Alpha greatly, but we should all be informed of whatever limitations exist before starting a project. My apologies if I have been too forward. My bad.

              You are mis-informed.

              You say: 'professional services are need to printing reports'.

              No. That is ridiculous and flat out wrong.

              There are tens of thousands of A5 web apps that do printing and our professional services have had no involvement with those projects.

              Perhaps you are getting confused with print spooling solutions that some users want to implement.

              Say that you have a very complex report that might take several minutes to print and that many people are likely to want to print at the same time.

              It makes no sense to do this type of report in real time because you will tie up the server. So instead of printing the report immediately, you create a new 'print job' in a database.

              A separate A5 instance then processes the print jobs.

              You can certainly set this up yourself, or have our professional services group set it up for you.

              Comment


                #97
                Re: Successful 6 Instances of WAS

                Originally posted by christappan View Post
                Mauricio,

                You win for the most active brainstormer.

                #1 is what I asked about, but if the driver doesn't create a queue, won't it have the same issues regardless of how many places (IPs) the print jobs come from?
                lol thanks, It should work that way, I think the problem comes from multiple WAS trying to access the PDF driver at the same time but thats would not be the case in this alternative
                Cheers
                Mauricio

                Comment


                  #98
                  Re: Successful 6 Instances of WAS

                  Mauricio

                  Can you elaborate on your brainstorm. I use a tabbedui for most of my reports and most of them have arguments how are you thinking about sending that off to a seperate WAS. I'm guessing that the first WAS would never print anything then otherwise you are back to the same problem?

                  Thanks
                  Chad Brown

                  Comment


                    #99
                    Re: Successful 6 Instances of WAS

                    Mauricio may have more to say about this, but working with me on this issue a few weeks ago, he suggested using Action Javascript buttons to call an a5w page with report-creating code, and in the url for the a5w page you could specify the port number (and therefore a single WAS instance). The problem with this (from my perspective) is that you can't use the action Javascript report functionality the way it's intended, and maybe I've done something wrong with this piece in the past, but the Action Javascript report generator seems to be a lot quicker for me than the a5w page method.

                    Comment


                      Re: Successful 6 Instances of WAS

                      Originally posted by Selwyn Rabins View Post
                      You are mis-informed.

                      You say: 'professional services are need to printing reports'.

                      No. That is ridiculous and flat out wrong.

                      Selwyn thanks for your response but I think I have to correct this to the orginal post at:
                      http://msgboard.alphasoftware.com/al...t=86926&page=3.
                      Also there is no negative response from Chris his answer but merely a question in concern towards the answer given in that post , both Chad and Chris have or wil run large enterprise application where you simply can't have these type of questions resetting server for any reason once a day. That is the basic question and positive point is to find a solution in good cooperation i am sure you agree.



                      There are tens of thousands of A5 web apps that do printing and our professional services have had no involvement with those projects.

                      Perhaps you are getting confused with print spooling solutions that some users want to implement.

                      Say that you have a very complex report that might take several minutes to print and that many people are likely to want to print at the same time.

                      It makes no sense to do this type of report in real time because you will tie up the server. So instead of printing the report immediately, you create a new 'print job' in a database.

                      A separate A5 instance then processes the print jobs.

                      You can certainly set this up yourself, or have our professional services group set it up for you.

                      Comment


                        Re: Successful 6 Instances of WAS

                        yes the idea is passing variables in the URL to an a5w page that contains the code to print an specific report. and the url should contain the port on which the WAS dedicated to Reports-Only is located. the url would be for example:

                        Code:
                        www.MySite.com:81/Print.a5w?Report_Name=Report_1&Country=Mexico&City=Torreon&UserID=Mauricio
                        the "Print.a5w" page would garb the variables from the url create the required filter and then execute the report (I have tested this in the past and it works)

                        and since you are using tabbed UI the url would be partially hidden to users
                        Cheers
                        Mauricio

                        Comment


                          Re: Successful 6 Instances of WAS

                          Let me summarize the Amyuni printing situation.
                          1. If you run one Application Server instance per server, there are no limitations on printing reports. The server can be a VPS or Hyper-V partition: it doesn't have to be a physical server
                          2. If you run multiple Application Server instances per multi-core server to handle high numbers of simultaneous users and have light reporting needs, you should be fine
                          3. If you run multiple Application Server instances per multi-core server to handle high numbers of simultaneous users and have heavy reporting needs (many users running long reports), you should consider a different architecture because you may occasionally get into contention situations with the shared Amyuni printer driver.
                          4. One option for heavy reporting needs is to split the multi-core server into Hyper-V partitions. That way each Application Server instance will have its own dedicated Amyuni driver and real-time report generation is possible.
                          5. Another option for heavy reporting needs is to send the report requests from the web app to a dedicated web or desktop app that queues them, prints them one at a time, and emails the resulting PDFs to the users. This is preferable if the reports are very long or CPU-intensive, as you don't want to kill the scalability of the Web server by making it generate a lot of big reports.
                          6. Alpha understands the problem is considering building a high-volume web report server that will eliminate the need for workarounds

                          I'm going to close this thread now, as it is becoming too long to manage.
                          Last edited by mheller; 10-06-2010, 11:48 AM.

                          Comment

                          Working...
                          X