Author Topic: Error message  (Read 4962 times)

Insanegame27

  • Full Member
  • ***
  • Posts: 144
  • Karma: +7/-3
  • I am the Bopmaster, master of Bops.
    • View Profile
Error message
« on: October 10, 2016, 01:50:11 PM »

So I got this error when trying to mobilise my soldiers. Even when I know the number is less than 200.


Quote
Warning: Unknown: Input variables exceeded 200. To increase the limit change max_input_vars in php.ini. in Unknown on line 0


Fatal error: Uncaught exception 'RuntimeException' with message 'Failed to start the session because headers have already been sent by "" at line 0.' in /home/maf/symfony/app/cache/prod/classes.php:118 Stack trace: #0 /home/maf/symfony/app/cache/prod/classes.php(192): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() #1 /home/maf/symfony/app/cache/prod/classes.php(492): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->getBag('attributes') #2 /home/maf/symfony/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/ContextListener.php(78): Symfony\Component\HttpFoundation\Session\Session->get('_security_accou...') #3 /home/maf/symfony/app/cache/prod/classes.php(3012): Symfony\Component\Security\Http\Firewall\ContextListener->handle(Object(Symfony\Component\HttpKernel\Event\GetResponseEvent)) #4 [internal function]: Symfony\Component\Security\Http\Firewall->onKernelRequest(Object(Symfony\Component\HttpKernel\Event\GetResponseEvent), 'kernel.request', Object(Symf in /home/maf/symfony/app/cache/prod/classes.php on line 5337


And if it's worth anything: No, the soldiers did not mobilise.
Now I have a mental image of horses lined up in a goods factory, building things on an assembly line.

Weaver

  • Full Member
  • ***
  • Posts: 249
  • Karma: +53/-42
    • View Profile
Re: Error message
« Reply #1 on: October 10, 2016, 02:18:45 PM »
It may have something to do with javelins, but I am not completely sure on that one. The math on the system is fucking up hard when it comes to resupplying them, and I have no god damn clue what is happening with that error message. It has to be a server-error because you could mobilize 500 soldiers before, javelins or not.

Weaver

  • Full Member
  • ***
  • Posts: 249
  • Karma: +53/-42
    • View Profile
Re: Error message
« Reply #2 on: October 12, 2016, 02:50:40 PM »
I just checked the code and couldn't find the reason for this bug. I thought it happened when resupplying javelins, but I am not so sure anymore. I would need to test this with resupplying 100 javelins, but if someone else can do this and report back let me know. if it's just mobilizing militia, then I would know what to focus in on. It worked before, so the ideas I have about what may be causing it are probably not relevant.

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1831
  • Karma: +75/-8
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: Error message
« Reply #3 on: October 13, 2016, 12:18:45 AM »
Seems to me that a maximum variable limit set in the php initialization file is being hit.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Insanegame27

  • Full Member
  • ***
  • Posts: 144
  • Karma: +7/-3
  • I am the Bopmaster, master of Bops.
    • View Profile
Re: Error message
« Reply #4 on: October 13, 2016, 01:40:14 PM »
And how would this be fixed?
Now I have a mental image of horses lined up in a goods factory, building things on an assembly line.

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1831
  • Karma: +75/-8
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: Error message
« Reply #5 on: October 13, 2016, 03:21:37 PM »
And how would this be fixed?

Changing the settings server-side to allow more variables. "To increase the limit change max_input_vars in php.ini." Where php.ini varies a little by OS and server setup, and depending on the host may not even be accessible. I've been too sick lately to do much of anything besides work and sleep the last few days, but hopefully I'll have some free time this weekend.

That said, this could be a code error somewhere if this limit is already something ridiculous and the game shouldn't be coming anywhere near it. I don't have access to the php.ini file the game's server uses to be able to answer that. Depending on the hosting setup, Tom may not even have access to it.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Weaver

  • Full Member
  • ***
  • Posts: 249
  • Karma: +53/-42
    • View Profile
Re: Error message
« Reply #6 on: October 14, 2016, 12:00:47 AM »
It is probably caused by a conflict in a custom class that overwrites httpkernel-- a controller most likely. I just have no clue why it worked before, and now doesn't.

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1831
  • Karma: +75/-8
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: Error message
« Reply #7 on: October 14, 2016, 09:53:44 AM »
Encountered this myself just now when trying to mobilize 120 or so soldiers. Doing about half that number seemed to work fine though.

Did give me an idea about how you could make mobilizing faster and easier though, which I'll jot down on a TODO list somewhere on the forum.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Insanegame27

  • Full Member
  • ***
  • Posts: 144
  • Karma: +7/-3
  • I am the Bopmaster, master of Bops.
    • View Profile
Re: Error message
« Reply #8 on: October 14, 2016, 02:00:14 PM »
I just tested it. It seems to happen when trying to work with over 100 soldiers. Sort into groups when you set them as militia?
Now I have a mental image of horses lined up in a goods factory, building things on an assembly line.

Cipheron

  • Full Member
  • ***
  • Posts: 209
  • Karma: +9/-4
    • View Profile
Re: Error message
« Reply #9 on: October 15, 2016, 11:17:23 AM »
vars = variables. The form is probably sending 2 pieces of data per soldier.

And that is correct. In the troops form you can in fact change two separate things. You can set the action (e.g. mobilize) and also change their group. That means sending two bits of data per soldier, and the website's php is geared to a limit of 200 vars per form processed.

This definitely counts as a bug. There are two possible ways to resolve that.

(1) JavaScript notices that the form is too big, and splits it into multiple ajax calls. This requires more calls but the advantage is it's only changing thing client-side, so less scripts to play with.

(2) change the way the data is sent. Chunk it all into a single block of text (one big variable), and have the website parse that back into separate variables. This strategy is better long-term since it could involve shrinking-down the size of the packets that are sent. The current method sends some very bloated strings. e.g. this is the bit that sends the action:

Code: [Select]
<select id="soldiersmanage_npcs_834953_action" name="soldiersmanage[npcs][834953][action]" class="action"><option value=""></option>            <option value="disband">disband</option>            <option value="assign">assign...</option><option value="makemilitia">set as militia</option><option value="retrain">retrain</option></select>
and

Code: [Select]
<select id="soldiersmanage_npcs_834925_group" name="soldiersmanage[npcs][834925][group]" class="action"><option value=""></option>            <option value="0">a</option>            <option value="1">b</option>            <option value="2">c</option>            <option value="3">d</option>            <option value="4">e</option>            <option value="5">f</option>            <option value="6">g</option>            <option value="7">h</option>            <option value="8">i</option>            <option value="9">j</option>            <option value="10">k</option>            <option value="11">l</option>            <option value="12">m</option>            <option value="13">n</option>            <option value="14" selected="selected">o</option>            <option value="15">p</option>            <option value="16">q</option>            <option value="17">r</option>            <option value="18">s</option>            <option value="19">t</option>            <option value="20">u</option>            <option value="21">v</option>            <option value="22">w</option>            <option value="23">x</option>            <option value="24">y</option>            <option value="25">z</option></select>

So to mobilize 100 soldiers it's sending the data "soldiersmanage[npcs][834953][action]=mobilize" 100 times. Plus sending "soldiersmanage[npcs][834925][group]=25" 100 times as well. That's 8.5K of data that's sent to mobilize 100 units, as well as being 200 vars, barring any additional overheads. As you can see, there's a whole lot of redundancy in the var naming scheme. in a call affecting 100 troops, the term "soldiersmanage[npcs][" turns up 200 times, "][action]=" turns up 100 times, and "][group]=" turns up 100 times.

The solution is to use JavaScript to vectorize all the data, and have the server unpack it again. After all, you're not going to do anything except "soldiersmanage" in a single call, so it would make sense to just have a variable at the top of the form telling the server which table this form is for, e.g.:

"formAction=soldiersmanage"
"mobilize=834955,834956,834957, ....,834953"
"group=834955:a,834956:b,834957:a ... 834953:d"

There ya go, three variables, the server unpacks the data back into the tabular form itself, and the per-unit amount is 16 bytes instead of 85 bytes, reducing packet size by 80%
« Last Edit: October 15, 2016, 11:50:25 AM by Cipheron »

De-Legro

  • M&F Dev Team
  • Sr. Member
  • *****
  • Posts: 3130
  • Karma: +105/-55
    • View Profile
Re: Error message
« Reply #10 on: October 19, 2016, 11:49:17 AM »
cept we didn't have this problem before when mobilising hundreds more troops. Sure the current set up is not efficient, but the bug is new with no change that I am aware of.
He who was once known as Blackfyre

Cipheron

  • Full Member
  • ***
  • Posts: 209
  • Karma: +9/-4
    • View Profile
Re: Error message
« Reply #11 on: October 19, 2016, 01:49:54 PM »
It's in php.ini. That's the servers initialization script, and is not part of the game. Access to that script depends on who is server admin (not the game admins). If they're renting space on a server, then the owner controls what's in that script. Also, it requires a phsical server reboot after changing that file for the effect of changes to work. So if it's a shared server, then it would have to happen when all games are going down for server maintenance.

The "vars limit" was added by PHP as a security measure, e.g against spamming fake forms which use a lot of vars for DDOS attacks (all those vars need to be stored in memory rather than as a data stream on disk). Originally, PHP set the vars limit to 1000 by default. Later, the owners of this server might have gone through and tweaked settings for extra security - including dropping the vars limit.

Basically, the devs could ask for the vars limit to be reset to 1000, which it almost certainly was before, but that's just passing the buck. e.g. I can do some actions for up to 66 troops. 3 vars per troop, limit of 200 vars per action. Raising it back to PHP's default of 1000 means the bug is still there, you just need to be working with 333 troops for it to trigger, which isn't hard to achieve. So the lower limit exposed the bug, it didn't create it. Changing things so that data is sent in a single block instead of separate vars would circumvent any need to worry about the exact vars limit, while also not having to ask the server admins to weaken a security measure.
« Last Edit: October 19, 2016, 02:18:51 PM by Cipheron »

Weaver

  • Full Member
  • ***
  • Posts: 249
  • Karma: +53/-42
    • View Profile
Re: Error message
« Reply #12 on: October 20, 2016, 12:25:51 AM »
I mobilized the max troop number before, which is 500. No errors.

It's not just complaining about being sent too many vars, it's also complaining about classes.php and kernel.request. It could be a mix of server side config changes and however Tom handles controllers.

Cipheron

  • Full Member
  • ***
  • Posts: 209
  • Karma: +9/-4
    • View Profile
Re: Error message
« Reply #13 on: October 20, 2016, 03:00:41 PM »
I stand by what I said about solutions:

(1) break up the form so that it sends data in chunks the server will accept (easy but messy, and if the drop the vars limit again the bug comes back)
(2) ask the server's owners to increase the vars limit (clean, but not an improvement on the old system, also: lowers server defense against DDOS attacks)
(3) send the data in a block instead of 1000 separate vars (will reduce server load and latency)

#3 is clearly the best solution since it would reduce server load while also avoid issues with sending 100's of vars per form.

If there are other errors popping up they may be related to different server config changes than this one.
« Last Edit: October 20, 2016, 03:10:32 PM by Cipheron »