CodeCharge Studio
search Register Login  

Web Reporting

Visually create Web Reports in PHP, ASP, .NET, Java, Perl and ColdFusion.
CodeCharge.com

YesSoftware Forums -> CodeCharge Studio -> PHP

 Logic Puzzle: Program goes berserk on Linux

Print topic Send  topic

Author Message
pbarkley

Posts: 37
Posted: 09/03/2015, 8:10 PM

BACKGROUND

I have a sizable CCS 5 application with many screens and tables. It does some fairly complex data manipulation in places, but I can demonstrate that on a very simple button click that does nothing more than truncates a table, this application will run flawlessly on a Windows Vista machine and go berserk on two different Linux servers. Please give me some suggestions if you’ve ever seen this kind of behavior before. Let me give you some more info. I’ve run out of ideas. Describing what the program does is a little complicated, but it screws up spectacularly on the most basic functions.

HOW IT WORKS AND CODING EVENTS

The purpose of this particular screen is to read a series of records for a planning zone and a particular year. The years can vary but look like 2015, 2020, 2025 and so forth for up to 20 different years. It then pivots the data so that each row is a zone, and each column is another year. Once the data is in the pivot table, it’s treated just like any CCS table.

So the Before Initialize event for the page does the heavy lifting to walk through the records and fill this temporary pivot table correctly as described above. Once the table is loaded it adds two more records. One record is the sum of all the records in that column, like a spreadsheet summing at the bottom, and one is summary data obtained from another table that is displayed for comparison. It always works perfectly, regardless of server or browser, and the table can be inspected in phpMyAdmin, etc. , for accuracy. It displays correctly, with the two summary records falling to the bottom where they belong, and the table can be paged through correctly in the grid. A typical scenario will have about 150 zones, so maybe 3 pages of 50. So far so good.

The Before Show event on the grid sets the column labels to the correct years by reading the set of years associated with this particular scenario since we don’t know what years we’re dealing with. So that’s a little unusual but not hard to understand, and also always works perfectly. I can’t just say the first column is “2015” because it might start with “2014” instead. But these are just labels. A little unusual, but not difficult.

The Before Show Row has one small task to perform. Each row has a couple of links that can be used to tell the system to move the data in a given row, and these have to be turned off for the two summary rows. Again, maybe a little unusual but simple to understand.

Now there are three buttons at the bottom of this grid, and two of them do complex stuff. One saves the temporary table back to the permanent records that were used to build the table, and the other does a fairly complex manipulation of the data moving rows out (delaying by 5 years) or in to match the overall curve row. However, these two buttons are IRRELEVANT to the issue—I only mention them because there is a lot of code behind them with nested loops.

WHERE IT GOES CRAZY AND TEST RESULTS

The third button, “Clear Pivot Table” illustrates the problem. All it does is truncate this pivot table (one SQL statement, obviously) so the user can start over if the data looks bad. OK, it also truncates the error log that was used to detect some bad data when loading the pivot table. But that’s it! It doesn’t do anything else!

When I run this on a Windows Vista machine (yeah I know), it runs perfectly. I can run a scenario with 150 zones (tested with 15 or 16 years) and everything works correctly. I can empty the pivot table, or I can even run the much more complicated buttons. I can also manually edit anything in the grid if I want and Submit it, because it’s a regular grid operating on a (now) regular underlying table.

However, when I run it on Linux server #1, extensive testing shows that it will work perfectly up to 40 zones (plus the 2 summary rows, so 42 rows). With even one more zone—and it doesn’t matter where I take the data from, even from other scenarios, so it’s not related to specific data values—the “Clear Pivot Table” button will not only not fire, some process will knock random “cells” out of the display and clear the totals! There are no functions to do either of those things! Inserting diagnostic statements to just echo and die in the On Click event for the button shows that it’s not even firing. I can’t get it to even say hello and die.

And BTW, the identical SQL truncate code, literally copied to a separate page whose purpose is to do an emergency clear of the pivot table while I’m debugging, works perfectly of course, just as it does on a Windows machine.

The same data destruction can be seen if I try to Submit the page, with or without changing any values on it.

Testing on server #2 shows that it will not run properly with any rows at all. The clear button and submit button both trash part of the data with even 1 or 2 rows!

I’m out of ideas about what I can do. There is an array that is initialized during the loading of the table for the study years (so I can load those column headings) and an array that holds the list of 150 zone ids so I can walk through them as needed. But they’re one dimensional and only store an integer, and they disappear (I think) when the initialization (or the end) process concludes.

Obviously if I can’t even use a button to truncate a table or do a Submit, then I certainly can’t rely on the two more complex buttons to run.

Of course I have the exact versions of Apache, PHP, and MySQL for all three machines and can supply those, but they’re all very close. If the problem is a difference in one of the hundreds of configuration settings, I don’t know where to look. The two Linux machines are shared machines from MediaTemple—#1 is an old gridserver that we’ve had, and #2 is a new DV (dedicated virtual) server. I don’t know how much memory #1 has because I can’t tell, but #2 only has 2 GB to run Apache and MySQL on the same box. Still, the rest of the program runs great, and even this particular page will load faster on the DV server. I also tested this on Chrome, Firefox, and IE and the results are identical.

Anyone have a similar experience where a CCS app runs great on Windows and then goes totally crazy on Linux? Sorry for the length of this post, but I didn’t know how to describe the situation any more succinctly and still give enough information to elicit a reasonable response. I can’t be the only person who has seen weird behavior like this.

Thanks for any suggestions!
View profile  Send private message
DataDoIT
Posted: 09/04/2015, 7:53 PM

You didn't mention if you've looked into the Linux logs directly.
/var/log/messages, /var/log/httpd/error_log, access_log, etc.

Also check to see if there's a difference in whether or not a persistent
connection is being used.
pbarkley

Posts: 37
Posted: 09/04/2015, 9:23 PM

Good suggestion, no I didn't check the Linux logs. I don't know that much about them, but I'll look ASAP.

What's your thinking with the persistent connections and how that might play into this? I'm pretty clueless with this bizarre behavior.

Thanks for the reply!
View profile  Send private message
DataDoIT
Posted: 09/05/2015, 11:38 AM

The Persistent Connection will use the same connection to do many
database related tasks. Mostly good for reg'lar ole read and writes,
lookups, etc. to keep things speedy. But it sounds like in your
scenario it doesn't qualify as "reg'lar".

You may also want to see about the MySQL max connections setting, open
files limit, even max allowed packets.

These are things that wouldn't necessarily rear their ugly heads on a
local Windows development platform where MySQL is in a compiled binary
state. On Linux, however, in a multi-user environment, all resources
matter.

Start by turning off Persistent Connection for your server connection
settings, and see if that helps. If that helps, then you'll want to
adjust the above parameters to a point where you can turn Persistent
Connection back on.
aewhite901

Posts: 35
Posted: 09/07/2015, 7:35 AM

What distro are you using for the server?

Try logging the MySQL queries using this.
You may find issues in that area.
[mysqld]
# Set Slow Query Log
long_query_time = 1
slow_query_log = 1
slow_query_log_file = /var/log/slowquery.log
log_queries_not_using_indexes = 1

#Set General Log
general_log = on
general_log_file=/var/log/general.log
View profile  Send private message
aewhite901

Posts: 35
Posted: 09/07/2015, 7:37 AM

Hmm, add this as well.

[mysqld]
query_cache_size=32M

You can run out of memory for a single transaction particularly if it returns a mass of data.
View profile  Send private message
pbarkley

Posts: 37
Posted: 09/07/2015, 8:19 PM

DataDoIt and aewhite901, thanks for the thoughtful replies. I was traveling this long weekend, so I'll start tomorrow working my way through these suggestions, and report back. It's going to take me a while to figure out how to check some of these things, but these are some great suggestions, thanks. After 3 or 4 years with CCS and not having run into anything even remotely like this, I'm feeling like a newbie again. :-< With the exception of a few very annoying bugs, the vast majority of my CCS problems have been self-induced, and therefore self-correctable. This seems like an entirely new realm of problems, but it sounds like you guys have run into similar issues before. Thanks again.
View profile  Send private message
eratech


Posts: 513
Posted: 09/08/2015, 10:54 AM

pbarkley - the 'truncate' problem does sound strange.

I've recently done an admin page to load up an email queue, and clear it as needed (using straight 'truncate table newsletterqueue' query and no problems with speed or patchy removal. 11K records in about 2 seconds.

Runs same on WAMP (Dev) and Debian Linux (Production)

Of course it's a single table and no pivots or other stuff involved so I might have a very different situation than yours. The memory and connection stuff sounds interesting (and bloody annoying!)

Cheers

Eric
_________________
CCS 3/4/5 ASP Classic, VB.NET, PHP
Melbourne, Victoria, Australia
View profile  Send private message
pbarkley

Posts: 37
Posted: 09/14/2015, 10:13 AM

OK, after THREE WEEKS of screwing around with this (not full time fortunately) I finally identified the problem, and of course the workaround only took 5 minutes. I don't know the exact reason for the issue, but as everyone suggested, it's definitely related to some settings on the two Linux servers.

First, I don't have access to any of the Linux logs, Apache logs, or MySQL logs on one of the shared servers. I did spend some time working on the second server where I have a little more control, but I was not able to identify any logged problems, nor was I able to identify, among the hundreds of settings in MySQL, etc., any significant differences in buffer sizes and so forth, compared to my development machine. Part of the problem is that these are not areas that I have any skill with, and part is that these shared machines have some limitations.

This is an extremely complicated program, and I eventually broke it up into 6 separate programs for testing, so that the process of loading the table, for example, happened in one program, which then passed off control to the display program. The various buttons, some of which were associated with a lot of procedural style code, were broken out to other programs from the display.

The editable grid has a lot of complexity on it, too, with links on each row to slide all the columns out one place, or move them in the other direction one place. Eventually I wrote a test grid with all of the complexity removed. All it had to do was display the table, consisting of about 20 columns and 150 rows of integer data.

This didn't work, either! And really, 150 rows is nothing--we all have tables much larger than that.

However, the problem turned out to be rather simple. I was displaying 50 rows per page, and the servers simply couldn't handle 50 rows by 20 columns. Any update to any "cell" in this display followed by the Submit would result in totally trashing 8 to 10 of the rows, and in addition destroying half the cells in another row, the same problem I had been having before with all the complexity. Well, the simple truncate command from one button on this display screen was also not firing, but the table was getting partially trashed from that button. As I said earlier, this simple code would run elsewhere fine.

The work around was simply to reduce the number of rows displayed to 10. Then the test program started working perfectly on the servers, and in fact the real program, with all the functions and complexity, also started working fine with 10 rows. Un-freaking-believable. Perhaps someone else reading this will think, what a moron, you should of thought of that 3 weeks ago!

I have placed a trouble ticket with Yes asking them if they're aware of what memory or other limitation might cause this behavior, but for now the client is able to continue using the program, even though 10 rows is definitely not optimal. In fact they'd like to see all 150 rows because the last two are the critical summary rows, but after all this angst, everyone is happy to have the program running and doing its complex data manipulation. For some of the client's clients, there may be eventually as many as 1,500 rows, so certainly there are concerns about how long it takes to run some processes. At this point, I'm not concerned about the display, since I think it's just related to how much data is presented on the same screen, not how many total rows there are.

There is another issue that turned up during repeatedly building test programs with grids, and that is the grid builder and the editable grid builder choke on this particular file. There are 3 or 4 columns, and then 20 columns called HUF01, HUF02...HUF20. There are two more sets of 20 columns with similar names, but they're not displayed in this grid. The grid builder will build everything nicely up to HUF07, but then it screws up HUF08 and HUF09 and then continues correctly for HUF10 to HUF20. You can see that by the messed up columns created there, and also the error is carried through to all the code that's generated. There are two consecutive lines where HUF7 is referenced before hitting HUF10 and eventually coming back to HUF8 and HUF9 (no zeroes in their text box references) after HUF20. So clearly either the field names or the number of columns confuses the builder. I've submitted this as a ticket to Yes to investigate along with the SQL to build the table. Obviously this is not a show stopper, but it would be nice to see a fix for it.

Thanks to those who responded with ideas, and hopefully this incident may prove helpful to someone else in the future.
View profile  Send private message
DataDoIT
Posted: 09/14/2015, 5:27 PM

That said, what you describe points towards PHP resource values, such as
maximum memory allocation, HTTP post size, even maximum execution time.

Now lemme toss in an unasked-for opinion on shared hosting.... Don't.
It's insecure to the point of it ought to be illegal should there ever
become some internet authority to police it, and then it doesn't allot
you the granular controls often needed (as you've experienced) in
complex applications.

Sign up an account at Amazon Web Services and be in complete control of
your own hosting environment on what is arguably the world's best
network infrastructure. Install a web GUI management console such as
Webmin and have the server management simplicity needed to be
productive. Three weeks of lost time is an expensive proposition if you
value your time, all to save maybe $10 a month?
pbarkley

Posts: 37
Posted: 09/14/2015, 6:08 PM

DD:

What? No, $10 is pretty much what 3 weeks of my time is apparently worth. :-)

First, I understand what you're saying. One issue is that I don't want to maintain servers and patch them. I want to build software applications and not deal with security, etc. I've been very satisfied with MediaTemple's gridservers up to a point. They work great for web hosting, and I have never been hacked there. We also maintain shared servers at other data centers, partly because of purchasing some small hosting businesses and dealing with clients already in place with other providers, and for sure we've had so many hacking problems at one location (on a Windows server) that we have managed to get all the clients except one off there and rewrite their ASP to PHP and put them on Linux servers. The last one comes off next month and we'll be able to close that account as well.. So I absolutely understand what you're saying. I do think it depends more on who the data center is. I've been impressed with MediaTemple's approach to security; when they found an exploit with a particular WordPress plugin, they just went through all their servers and killed the plugin! I was rather shocked, but it was way better than getting hacked.

Most of the time the lack of control is not a problem for us. If we put up a WordPress site, for example, the limited control of MySQL and PHP and Apache is not an issue. MySQL and the email server are on separate boxes. I have one client that needs a larger "container" and we pay extra for that, and as part of that service we get the MySQL logs, the ability to reboot the MySQL server engine, etc.

Recently we purchased our first "dedicated virtual" machine for about 3 times the monthly fee. We had to get control of our email server because the shared email server was frequently being blocked when some bad neighbor would spam someone. What I find now is that we have completely different control panels, and I have to do a lot more work to set up and maintain things. That's why I had so much trouble during this recent incident even figuring out where the logs were on the different servers; I still have more work to do there because this is a new box for us.

However, given the problems I had on this application in the past few weeks, yes, any different arrangement that actually worked would have been well worth the difference in cost.

I did receive a prompt reply to my trouble ticket today, although I think the conclusions are incorrect in my case. Yes says that CCS 5.1 will only work with PHP through version 5.3. While this MIGHT explain why the grid builder screws up on generating the code for the table, it does not explain why the table won't run with more than 10 rows. Obviously if something is deprecated (and the implication is that it will not run, not just generate a warning) as they claim, then it shouldn't work with any rows at all, so I'm not buying that argument. However, I do accept that CCS 5.1 shouldn't be run on PHP greater than 5.3 since they say so. And of course no commitment or even hint of when or if this deprecation will be fixed. I'm really hoping we see something soon from Yes, given the long delay since their previous release, because they're making me very, very nervous. I think the developers were all tied up on the Artisteer to Themler fiasco, but that's just supposition on my part. Seeing another release, even if minor, would do a lot to make me feel better about the product.

Thanks for the suggestion about Amazon. I'll certainly consider it. Also, I'm sure you're right about the resource issue, although I'm pretty sure it's not the max execution time, which is 30 seconds unless CCS does something to it. The reason I know that is that some of my processes run longer than that and I've had to set it longer and then set it back. I actually have two processes that way. I'm positive that displaying 50 rows of this data doesn't take 30 seconds, and updating those 50 rows with a Submit, while longer, is still under 30 seconds I think.

BTW, my attitude is that CCS is responsible for handling all this routine stuff--that's why I bought it. It may sound ignorant and short sighted, but I don't want to debug their code because for the most part I don't even understand what it's doing in the tens of thousands of lines that get generated. I'm not saying it's bad code, or good code, or whatever, just that if I wanted to write all this by hand I wouldn't be using CCS. In fact I have written code generators going back to original dBase and Clipper days, and even some special niche html generators from Access, but in this case I really didn't want to get into anything more than using the system as it was intended, including custom inserts and updates, special code for list boxes, or whatever for my special needs. I don't want to fight with their concept of code generation or try to patch it. I dunno, maybe that's just not a realistic attitude here. Once you waste this much time on something, you start wondering if you should even be using this tool, and I don't want to go there right now.

Thanks for the input, DD, I appreciate it.
View profile  Send private message
DataDoIT
Posted: 09/15/2015, 10:40 AM

Great info. At some point in time Yes Software will recognize where the
greatest potential lies. I like to think of them as Microsoft, and
Microsoft spending all of their time, attention and money on Paint
rather than on Windows itself.

Add new topic Subscribe to topic   


These are Community Forums for users to exchange information.
If you would like to obtain technical product help please visit http://support.yessoftware.com.

PHP Reports

Visually create Web Reports in PHP, ASP, .NET, Java, Perl and ColdFusion.
CodeCharge.com

Home   |    Search   |    Members   |    Register   |    Login


Powered by UltraApps Forum created with CodeCharge Studio
Copyright © 2003-2004 by UltraApps.com  and YesSoftware, Inc.