Jon Sonntag wrote, On 27.06.13 15:48:
Why not have the manage app versions page work the same as the manage
special users page with an update button per app version?
Could work. In principle I would be fine with any solution that could
deal with an arbitrary large app_versions table.
However in contrast to the manage special users page, for the manage app
versions page it's not enough to modify the database table. The changes
need to be communicated to the feeder to get into the shared memory. For
older versions of the server code touching the "reread_db" file was
enough, in newer versions the manage app versions page recommend to stop
and start the whole project for every change (*). I'm not sure you would
want to do this for every change you do to every single app version. The
current mechanism at least allows to make many changes at once, before
making the feeder read the changes.
Best,
Bernd
(*) I'm not sure if that is really necessary, though; I can hardly
imagine what should be required beyond stopping the scheduler,
restarting the feeder and allowing the scheduler again. But it might be
that for most projects restarting the project (including restarting all
daemons) is easier and not much slower than just restarting the feeder.
Jon Sonntag
On Thu, Jun 27, 2013 at 4:48 AM, Bernd Machenschalk
<[email protected] <mailto:[email protected]>>
wrote:
Hi!
Recently the manage_app_versions.php suddenly messed up our
app_version table. All 'deprecated' flags together with all min
and max client version specifications were gone (i.e. set to 0).
Work was sent out with app versions it was never meant to be. The
damage couldn't be repaired using this same page. I spent half a
night to manually fix the table in the DB.
This could happen to every unsuspecting project at an
unforeseeable time, leaving no obvious way to fix it.
Here's why:
- the form in the page builds a POST string containing elements
for ALL rows in the app_versions table, i.e. the size of the POST
string grows with the table length
- of course the length of the POST buffer is limited (in the
Apache configuration IIRC)
- the current way the POST string is interpreted has no way to
distinguish between a value of zero and a value not being given at
all.
Consequently all values that are missing e.g. because of a
truncated POST string are assumed to be 0 and entered in the DB as
such. As there is no way to shorten the POST string, there is not
even a way to correct such errors using that page.
For us this happened with 436 app versions in the table, but this
number is really arbitrary. The length of the (resulting) POST
string e.g. depends on how many of these versions are (already)
deprecated.
Most of our app versions relate to older apps that are now
deprecated. So for us and for now the quick workaround was to skip
the versions of deprecated apps (patch 0001), both when showing
the list and when processing the form. This, however, is
dangerous: It relies on the 'deprecated' status not changing
between these two queries: when the list to be shown is built and
when the updates are performed.
In order to prevent the page from completely messing up the table,
I added a small check for 'completeness' of the POST string (patch
0002). This adds a hidden element (presumably) at the end of the
POST string and prevents any updates from being executed when this
end tag didn't make it through.
All of these measurements, however, don't really fix the root
problem. To do that one would need to rewrite the whole mechanism
how the information which updates are to be performed is passed. I
don't really have time for this now, maybe someone else has.
Best,
Bernd
_______________________________________________
boinc_dev mailing list
[email protected] <mailto:[email protected]>
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
