| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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...
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
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.
|
|
|
|
| |
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.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
17:14:28 - [APPLICATION]:
APPLICATION EXCEPTION DETECTED: System.UnhandledExceptionEventArgs
Exception: System.InvalidOperationException: Operation is not valid due to the current state of the object
at System.Collections.Generic.Queue`1[OpenSim.Region.ClientStack.Linden.WebFetchInvDescModule+aPollRequest].Peek () [0x00011] in /root/install/mono-3.1.0/mono/mcs/class/System/System.Collections.Generic/Queue.cs:158
at System.Collections.Generic.Queue`1[OpenSim.Region.ClientStack.Linden.WebFetchInvDescModule+aPollRequest].Dequeue () [0x00000] in /root/install/mono-3.1.0/mono/mcs/class/System/System.Collections.Generic/Queue.cs:140
at OpenSim.Framework.DoubleQueue`1[OpenSim.Region.ClientStack.Linden.WebFetchInvDescModule+aPollRequest].Dequeue (TimeSpan wait, OpenSim.Region.ClientStack.Linden.aPollRequest& res) [0x0004e] in /home/avacon/opensim_2013-07-14/OpenSim/Framework/Util.cs:2297
|
| | |
|
|/
|
|
|
|
|
| |
handlers.
This adds explicit cap poll handler supporting to the Caps classes rather than relying on callers to do the complicated coding.
Other refactoring was required to get logic into the right places to support this.
|
|
|
|
|
| |
Add a GetStatsAsOSDMap method to StatsManager which allows the filtered
fetching of stats for eventual returning over the internets.
|
|
|
|
|
|
|
|
| |
returned 499 and the exception message in the http_response event rather than the actual response code and body.
This was a regression since commit 831e4c3 (Thu Apr 4 00:36:15 2013)
This commit also adds a regression test for this case, though this currently only works with Mono
This aims to address http://opensimulator.org/mantis/view.php?id=6704
|
|
|
|
| |
requesting.
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
This happens in HEAD handlers.
|
|/
|
|
|
|
|
|
|
| |
to print various counts of capability invocation by user and by cap
This currently prints caps requests received and handled, so that overload of received compared to handled or deadlock can be detected.
This involves making BaseStreamHandler and BaseOutputStream record the ints, which means inheritors should subclass ProcessRequest() instead of Handle()
However, existing inheriting classes overriding Handle() will still work, albeit without stats recording.
"show caps" becomes "show caps list" to disambiguate between show caps commands
|
|
|
|
| |
This reverts commit c95a23863ab51810ccc01afd3dd641c18a183305.
|
| |
|
| |
|
|
|
|
| |
This didn't seem to be working anyway and it's better not to have such hacks in the code for experimental stuff.
|
| |
|
|
|
|
|
|
|
|
| |
This is in order to reduce the likelihood of naming clashes, make it easier to filter in/out attributes, ensure uniformity, etc.
All dynattrs in the opensim distro itself or likely future ones should be in the "OpenSim" namespace.
This does alter the underlying dynattrs data structure. All data in previous structures may not be available, though old structures should not cause errors.
This is done without notice since this feature has been explicitly labelled as experimental, subject to change and has not been in a release.
However, existing materials data is being preserved by moving it to the "Materials" store in the "OpenSim" namespace.
|
| |
|
|
|
|
|
|
| |
Also round this and ProcessMemory to three decimal places in common with other memory stats.
I believe leaving out such minor info makes stats easier to read
|
|
|
|
| |
e.g. "show stats httpserver.9000 server.network"
|
|
|
|
| |
rate" since this is more generally meaningful
|
|
|
|
|
|
| |
accidentally != null rather than == FireAndForgetMethod.SmartThreadPool
Due to another check this had no practical effect
|
|
|
|
|
|
|
|
|
| |
separating category and container with a period.
e.g. "show stats server.network"
I failed to realize this had already been implemented without the period in the show stats command (as the command help had not been updated).
However, I would prefer the . approach as it will allow specifying multiple stats, easier wildcarding, etc.
This commit also prevents any stat from having a period in its short name.
|
|
|
|
| |
server.network.HTTPRequestsMade in "show stats all"
|
| |
|
|
|
|
| |
httpserver.<port>.IncomingHTTPRequestsProcessed stat
|
|
|
|
| |
additional stat with sampling would produce wrong results
|
|
|
|
|
|
| |
"show stats server"
Also puts these and previous builtin threadpool stats in the "threadpool" stat container rather than "processor"
|
|
|
|
| |
threadpool to the ServerBase rather than being in Util
|
|
|
|
| |
command if threadpool type was QueueUserWorkItem (Unsafe worked as expected)
|
|
|
|
|
|
| |
This was the original intention with these stats, as I didn't believe they would be useful to ordinary users if everything is working as it should.
Please amend if this is an issue.
Just for now, levels actually have no impact on what is displayed via the "show stats" command.
|