| Pages: 1 2 3 [4] :: one page |
| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
xXkynraXx
   |
Posted - 2010.03.07 08:27:00 -
[91]
man this petition stuff is crap, i paid for game time on the third and actually logged in to my character, but ever since yesterday, every time i try to log in to my alternate characters account, i get this message: "unable to login, account disabled", i just friggin' paid for gametime on 03/03/10?...it still has not been taken care of, and i'm starting to get angry...
|
Darek Castigatus
Immortalis Inc.
Shadow Cartel
|
Posted - 2010.03.07 14:57:00 -
[92]
 Originally by: xXkynraXx
man this petition stuff is crap, i paid for game time on the third and actually logged in to my character, but ever since yesterday, every time i try to log in to my alternate characters account, i get this message: "unable to login, account disabled", i just friggin' paid for gametime on 03/03/10?...it still has not been taken care of, and i'm starting to get angry...
And this has to do with the topic being discussed how exactly??
|
Hack Harrison
Caldari
|
Posted - 2010.03.08 06:30:00 -
[93]
Originally by: xXkynraXx
man this petition stuff is crap, i paid for game time on the third and actually logged in to my character, but ever since yesterday, every time i try to log in to my alternate characters account, i get this message: "unable to login, account disabled", i just friggin' paid for gametime on 03/03/10?...it still has not been taken care of, and i'm starting to get angry...
Waaaaahhhhhh
|
Harris Dorn
|
Posted - 2010.03.11 05:09:00 -
[94]
Edited by: Harris Dorn on 11/03/2010 05:09:08
What you need to do is hire a team to setup a proper log that way you will have logs to show your mysterious vendor and you could look at the logs when we send petitions, see we are correct 90% of the time, laugh your butts off then tell us the logs show nothing.
|
Woody Hill
|
Posted - 2010.03.11 11:26:00 -
[95]
Hmmm,
CCP, have you tried turning it off and then turning it back on again.
Also sometimes my computer slows down when I open Firefox and SQL management studio at the same time. So try to stop people looking a you tube and the like, on your SQL server.
No charge for this valuable advice, but if you want to pop a Vindicator in my hangar we will call it quits.
kthxbai
|
Zenst
Aliastra
|
Posted - 2010.03.11 19:52:00 -
[96]
Edited by: Zenst on 11/03/2010 19:52:25
So has your `vendor` givin you a response like this yet:
Hi,
I have closed this petition as we can't give you any further advice on a fix for this. I hope you continue to enjoy EVE.
Best regards,
GM stupidfraggle
The EVE Online Customer Support Team
Seriously WTF, you break something then expect to palm people of with **** like that, you usless bunch of cnuts.
|
Lei Merdeau
Gallente
|
Posted - 2010.03.12 10:19:00 -
[97]
I've been having a ridiculous level of EVE freezing lately when most of the net keeps going.
Luckily I just reset my ASDL2+ modem and unticked the Enforce MTU option (1492 bytes.
Being over PPPoE I understand I should NOT do this.
However, EVE seems to be much happier.
Mean anything?
|
Argo Pyxis
|
Posted - 2010.03.25 22:08:00 -
[98]
Originally by: Bomberlocks
Originally by: CCP Valar
We know that problem lies in the TCP stack and likely has something to do with handling of closed or closing sockets... and Turning off recycling of idle sessions seems promising as a workaround that makes triggering the bug less likely
This is very naive and simplistic of me, but if the race condition is caused by the interaction between the way the TCP stack handles opening and closing sockets and db session pooling, and since turning off session pooling seems to solve the problem (but cause another due to increased overhead) doesn't it stand to reason that that tuning the size of the session pool might help solve the problem?
If the session pool is tuned proportionally to the number of open socket connections, accepting lag at higher connection numbers with increased reliability, perhaps you could keep the system running, albeit more slowly?
While this might work, the performance trade-off would be *drastic*
TCP connection setup and teardown, regardless of OS, is a relatively expensive thing to do (and by expensive, I mean in terms of time, not CPU or other hardware resources)
The concept of Connection Pools is part of any RDBMS system today and is de rigueur when setting up a database and its consumers to perform under high transaction loads... so keeping pooling off is a night and day difference, and not for the better. Other parts of the game app (the app which runs on their servers and converses with the database(s)) might not be geared towards dealing with the increased query time which will result, very likely causing a domino effect which may manifest in more serious problems than just slowness seen by users.
/AP
|
Pricecheck sama
|
Posted - 2010.04.01 10:13:00 -
[99]
http://en.wikipedia.org/wiki/Karnaugh_map
love that wiki. CCP needs this !
|
Beltantis Torrence
Groovy Guns
|
Posted - 2010.04.19 21:41:00 -
[100]
Originally by: Kerfira
Originally by: Gimme Sugar
Time to switch from SQL Server (Sybase) to Oracle RDBMS!
Why the hell would they switch from one monolithic database to another? They all have the exact same weaknesses.
If implementing something like EVE again, they should use a telco grade distributed X.500 directory server. Much faster and almost infinite data expansion capability (just add more server nodes).
For Eve? Eve is write heavy. A DS would be a terrible idea.
|
Beltantis Torrence
Groovy Guns
|
Posted - 2010.04.19 21:49:00 -
[101]
Originally by: Pilk
Originally by: Joe Censored
Edited by: Joe Censored on 03/03/2010 23:24:22
Originally by: Mithfindel
Originally by: Jason Edwards
I see alot of "our vendor"
microsoft? cisco?
IIRC, Microsoft SQL Server 2008.
Ah this is disappointing. Use of an open source base OS for the SQL server would allow internal CCP kernel devs to quickly spot this type of race condition and implement a fix without the need for consultation with any outside vendor. Proprietary OS's like Windows or Mac OS always mean they have you by the balls when or even if they find your problem important enough for them to fix.
(put several printk's in the TCP stack code at various places, and wait for the race condition and see what was last output... done you found the location of the issue, or at least how I would find it)
While I agree with you in principle, your point is misdirected. The problem is not in the TCP stack implementation in their OS, but in some combination of the way the DB server and clients cooperate on collection pooling and their monitoring for conditions necessitating failover. The best they could hope for as far as the type of debugging you propose is to run a sniffer on the segment in question, but the problem is that it's not easy to reproduce, so they'd be logging terabytes of data at minimum, if it's even possible for them to sniff and log on that segment in the first place.
Or, to put it in a slightly-simpler way: the problem is at Layer 5 or above (i.e., the app's handling of the TCP sessions), not 3/4.
One suggestion, if it it possible to do network-level logging: even a simple ring buffer approach would give you more than enough data, if it's tied into the failover system. Set it to log the last (amount of RAM minus 1GB or so), and add a trigger to your monitoring/failover system that turns off the logger (or have the logger notice the failover somehow).
--P
Or better yet just turn off automatic failover in favor of retrying since the failover isn't transparent anyway.
|
| |
|
| Pages: 1 2 3 [4] :: one page |
| First page | Previous page | Next page | Last page |