| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
requests timeout in 60 secs.
There's plenty of room for improvement in handling the EQs. Some other time...
|
|
|
|
|
|
| |
a continuous loop with sleeps.
Does appear to have a cpu impact but may need further tweaking
|
|
|
|
| |
This reverts commit 52dc7b2a96a28798d55d07d79d003ce5e3d35216.
|
|
|
|
| |
This reverts commit 5495df74436d6c0039a1500d979a964b003abfdf.
|
|
|
|
|
|
| |
count >0 is not the smartest move...""
This reverts commit 71278919575b0e0222cdbe3c0cefa5919f9a75bc.
|
|
|
|
| |
This reverts commit fda91d93dad1fa6f901e8db5829aa8b70477c97e.
|
|
|
|
|
|
|
|
| |
successfully tested, and I'm merging back those changes, which proved to
be good.
Revert "Revert "Cleared up much confusion in PollServiceRequestManager. Here's the history:""
This reverts commit fa2370b32ee57a07f27501152c3c705a883b13d8.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
where the q parmater is ignored and everyghig is always placed on m_lowQueue.
No actual impact presently since nothing ends up calling EnqueueHigh()
|
|/ |
|
|\ |
|
| |\ |
|
| | |
| | |
| | |
| | | |
to avoid kicking the wrong user or multiple wrong users.
|
| | |
| | |
| | |
| | |
| | |
| | | |
history:"
This reverts commit e46459ef21e1ee5ceaeca70365a7c881d33b09ce.
|
| | |
| | |
| | |
| | | |
This reverts commit 0f5b616fb0ebf9207b3cc81771622ed1290ea7d6.
|
| | |
| | |
| | |
| | |
| | |
| | | |
not the smartest move..."
This reverts commit f4317dc26d670c853d0ea64b401b00f718f09474.
|
| | |
| | |
| | |
| | | |
This reverts commit af792bc7f2504e9ccf1c8ae7568919785dc397c9.
|
| | |
| | |
| | |
| | | |
This reverts commit 1d3deda10cf85abd68a5f904d6698ae597a67cc0.
|
| | |
| | |
| | |
| | |
| | |
| | | |
PollServiceRequestManager."
This reverts commit 5f95f4d78e8c7d17b8ba866907156fe6d4444c04.
|
| |/
|/|
| |
| |
| |
| | |
the purpose of BlockingQueues. Trying this, to see the effect on CPU."
This reverts commit 5232ab0496eb4fe6903a0fd328974ac69df29ad8.
|
| |
| |
| |
| | |
purpose of BlockingQueues. Trying this, to see the effect on CPU.
|
| |
| |
| |
| | |
PollServiceRequestManager.
|
| | |
|
| | |
|
| |
| |
| |
| | |
smartest move...
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | | |
before the first simulator step.
|
|/ /
| |
| |
| |
| |
| | |
When Melanie added the web fetch inventory throttle to core, she made the long poll requests (EQs) effectively be handled on an active loop. All those requests, if they existed, were being constantly dequeued, checked for events (which most often they didn't have), and requeued again. This was an active loop thread on a 100ms cycle!
This fixes the issue. Now the inventory requests, if they aren't ready to be served, are placed directly back in the queue, but the long poll requests aren't placed there until there are events ready to be sent or timeout has been reached.
This puts the LongPollServiceWatcherThread back to 1sec cycle, as it was before.
|
| |
| |
| |
| | |
services throttle thread. Didn't change anything in how that processor is implemented, for better or for worse.
|
| |
| |
| |
| | |
the interface, so that duplicate requests aren't enqueued more than once.
|
| |
| |
| |
| | |
up the cache, because the resource may be here in the meantime
|
|\ \
| |/ |
|
| |
| |
| |
| | |
attachments module implementations. All calls to Scene.AttachmentsModule are checking for null. Ideally, if we support disabling attachments then we need a null attachments module to register with the scene.
|
|/ |
|
| |
|
|\ |
|
| |
| |
| |
| | |
from BlockingQueue.Contains(), Count() and GetQueueArray()
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
block will trigger a Monitor.Wait() to exit, so avoid some locks that don't actually affect the state of the internal queues in the BlockingQueue class.""
This reverts commit 21a09ad3ad42b24bce4fc04c6bcd6f7d9a80af08.
After more analysis and discussion, it is apparant that the Count(), Contains() and GetQueueArray() cannot be made thread-safe anyway without external locking
And this change appears to have a positive impact on performance.
I still believe that Monitor.Exit() will not release any thread for Monitor.Wait(), as per http://msdn.microsoft.com/en-gb/library/vstudio/system.threading.monitor.exit%28v=vs.100%29.aspx
so this should in theory make no difference, though mono implementation issues could possibly be coming into play.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
will trigger a Monitor.Wait() to exit, so avoid some locks that don't actually affect the state of the internal queues in the BlockingQueue class."
This reverts commit 42e2a0d66eaa7e322bce817e9e2cc9a288de167b
Reverting because unfortunately this introduces race conditions because Contains(), Count() and GetQueueArray() may now end up returning the wrong result if another thread performs a simultaneous update on m_queue.
Code such as PollServiceRequestManager.Stop() relies on the count being correct otherwise a request may be lost.
Also, though some of the internal queue methods do not affect state, they are not thread-safe and could return the wrong result generating the same problem
lock() generates Monitor.Enter() and Monitor.Exit() under the covers. Monitor.Exit() does not cause Monitor.Wait() to exist, only Pulse() and PulseAll() will do this
Reverted with agreement.
|
| | |
|
| |
| |
| |
| | |
reflect its more generic nature.
|
|/
|
|
| |
other one generic, taking any continuation.
|
|
|
|
| |
altogether. Instead, this uses a timer. No sure if it's better or worse, but worth the try.
|
| |
|
| |
|
|
|
|
| |
random crash might be in DoubleQueue instead. See http://pastebin.com/XhNBNqsc
|
|
|
|
| |
a random crash in a load test yesterday
|
|
|
|
| |
trigger a Monitor.Wait() to exit, so avoid some locks that don't actually affect the state of the internal queues in the BlockingQueue class.
|