wird es noch schlimmer bei gc.com ?

[Starglider]

Immer noch nix! So eine Sch.... :evil: :evil: :evil: :evil: :evil:

Könnte es sein, dass du ein pöser PQ-Poweruser bist?
Angeblich rutschen die Queries von Leuten mit vielen aktiven PQs ja in der Priorität nach unten. Ist nur so eine Idee.

 

[radioscout]

Könnte es sein, dass du ein pöser PQ-Poweruser bist?
Angeblich rutschen die Queries von Leuten mit vielen aktiven PQs ja in der Priorität nach unten. Ist nur so eine Idee.

Das könnte eine Erklärung dafür sein, daß es bei mir so schnell geht. Ich nutze ca. 1-2 PQs pro Woche.

Ich habe vorhin noch eine erstellt und die Email war wieder nach wenigen Sekunden da.

 

[Team-Crossgolf]

Bei mir gehts auch super zügig!

 

[alex3000]

Immer noch nix! So eine Sch.... :evil: :evil: :evil: :evil: :evil:

Könnte es sein, dass du ein pöser PQ-Poweruser bist?
Angeblich rutschen die Queries von Leuten mit vielen aktiven PQs ja in der Priorität nach unten. Ist nur so eine Idee.

Hmmm. Diese Woche habe ich insgesamt 14 PQs laufen gehabt - die Wochen und Monate vorher nur ab und zu mal 1 pro Woche.

Wenn das wirklich so ist: Frechheit! Wofür zahl ich dann für die PQs? Mir stehen 5 pro Tag und das jeden Tag zu!

Ach ja, die PQs sind dann gegen 22 Uhr eingetroffen - viele Stunden zu spät!

 

[radioscout]

Ich kann das Problem nicht nachvollziehen. Bisher kam die Email immer wenige Sekunden nach der Abfrage. Ich kann mich nicht erinnern, jemals auf eine PQ gewartet zu haben.

 

[Cornix]

Irgendwo hat mal jemand von Groundspeak erklärt, wie das ganze abläuft, ich kann's aber nicht mehr finden.

Aus der Erinnerung: es gibt einen eigenen PQ-Server mit einer Auftrags-Queue. Frisch angelegte PQs kommen ganz nach vorne in die Queue und werden deshalb relativ zügig abgearbeitet. PQs, die regelmäßig (täglich) laufen, haben demgegenüber eine niedrigere Priorität. Wenn ein Auftrag wegen der Auftragsmenge nicht am angekreuzten Wochentag ausgeführt werden kann, dann wird er gar nicht ausgeführt und man muss auf den nächsten angekreuzten Wochentag hoffen (sowas soll früher ein paar mal vorgekommen sein).

Darüberhinaus sollte man die Zeitverschiebung MEZ gegenüber PST (6 Stunden?) beachten. Eine PQ, die auf 'Friday' terminiert wurde, kann also theoretisch bis Samstagmorgen auf sich warten lassen.

Cornix

 

[radioscout]

Das erscheint mir plausibel und userfreundlich.
Wenn eine PQ ohnehin ständig läuft und regelmäßig Daten liefert wird es dem User sicher nicht darauf ankommen, daß die Mail exakt um 8 Uhr morgens da ist.

Wenn jemand zum Caches fährt und sich kurz vorher mittels einer dafür erstellen PQ die Daten runterlädt, ist er sehr froh, wenn die Daten möglichst zeitnah eintreffen.

 

[DocW]

Darüberhinaus sollte man die Zeitverschiebung MEZ gegenüber PST (6 Stunden?) beachten. Eine PQ, die auf 'Friday' terminiert wurde, kann also theoretisch bis Samstagmorgen auf sich warten lassen.

Cornix

9h zurück.

 

[alex3000]

Darüberhinaus sollte man die Zeitverschiebung MEZ gegenüber PST (6 Stunden?) beachten. Eine PQ, die auf 'Friday' terminiert wurde, kann also theoretisch bis Samstagmorgen auf sich warten lassen.

Cornix

Ich hatte früher immer ein PQ pro Woche laufen (fest eingestellt). Das war eigentlich immer um spät. 9 Uhr morgens da.

 

[Cornix]

Es könnte natürlich sein, dass in der Queue einfach nach PQ-Nummer sortiert wird. Dann rutschen PQs im Laufe der Zeit immer weiter nach hinten und trudeln immer später am Tag ein.

Als Abhilfe könnte man häufig benutze PQs umkopieren und ihnen dadurch eine neue Nummer verpassen. Das wäre mal einen Versuch wert.

Cornix

 

[JamesDoe]

Ich meine irgendwo mal gelesen zu haben das regelmäßig PQ immer hinten angestellt werden, und einmalige vorab bearbeitet werden. Ich habe mir meine PQ so eingerichtet das sie immer Donnerstag kommen, das reicht fürs Wochenende.

Und um zu sehen was bei mir in der Gegend neues kommt, benutze ich die entsprechende Benachrichtigungsfunktion.

Gruß aus Godesberg

Jens

 

[jensileinchen]

heydehoooooooo es is mal wieder so weit ....

Server Error in '/' Application.
Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.]
System.Data.SqlClient.SqlConnectionPoolManager.GetPooledConnection(SqlConnectionString options, Boolean& isInTransaction) +396
System.Data.SqlClient.SqlConnection.Open() +384
Groundspeak.Web.SqlData.SqlConnectionManager.FillDataSetSP(String StoredProc, ParameterList Params, Int32 Timeout, Database database) +117
Groundspeak.Web.SqlData.SqlUserController.GetUserData(String username, String password) +428
Groundspeak.Web.User.Validate(String username, String password) +36
Geocaching.UI.login_default.NewLogin() +82
Geocaching.UI.login_default.Button1_Click(Object sender, EventArgs e) +7
System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108
System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33
System.Web.UI.Page.ProcessRequestMain() +1262


Version Information: Microsoft .NET Framework Version:1.1.4322.2300; ASP.NET Version:1.1.4322.2300

naja was solls, wird auf die dauer langweilig diese meldung - sollten sich ma was neues einfallen lassen....

 

[Lion & Aquaria]

da logg ich mich einmal auf 2monate bei gc.com ein und schon geht nix mehr
Bei mir isses ein "Objekt reference not set to an instance of an object."
Absonsten schleße ich mich den husaren an

 

[Team-Crossgolf]

Also ich bin schon den ganzen Morgen am machen - bei mir gehts prächtig - ich weiß nach wie vor nicht, warum Ihr Probleme habt ?!?!?!

 

[Lakritz]

Ach du bist das.

 

[GeoFaex]

Also ich bin schon den ganzen Morgen am machen - bei mir gehts prächtig - ich weiß nach wie vor nicht, warum Ihr Probleme habt ?!?!?!

Dann geh mal aus der Leitung und lass jemand anders ran

Bin auch schon den ganzen morgen auf GC.com unterwegs. Läuft eigentlich ganz gut, nur für einige Minuten hatte ich mal keine Caches mehr

 

[Team-Crossgolf]

..keine Caches mehr

Dann mußt Du welche legen - OK, also ich bin jetzt draussen, aber nicht lange. Bin jetzt hier im Forum, aber nicht wundern, wenns jetzt hier langsam wird :twisted:

 

[GeoFaex]

..keine Caches mehr

Dann mußt Du welche legen

Bin schon dabei....

OK, also ich bin jetzt draussen....

Der nächste bitte...

 

[alex3000]

Dann mußt Du welche legen - OK, also ich bin jetzt draussen, aber nicht lange. Bin jetzt hier im Forum, aber nicht wundern, wenns jetzt hier langsam wird :twisted:

Da gabs doch mal für den C64 so eine Schnecke - ein Hardwaremodul, mit dem man Games langsamer machen konnte um mehr Reaktionszeit zu haben. Setzt Du sowas hier vielleicht ein?
BTW: Du gehst mit einem C64 ins Netz? :shock:

 

[Team-Crossgolf]

Das gibts nicht nur für den C64 :twisted: :twisted: :twisted:

Also ich gehe nicht mit nem 64er hier rein, aber manchmal könnte man meinen der Moenk hat nen 64er als Server für uns.