=====================================
I switched back to linux with my osgrid region.
I have some strange sideeffect on my train megasim, as soo the train is
rideing and am on the sim it seems to crash pretty fast
with a nice stacktrace and above that some slow requests on serveral parts.
22:16:02 - [BASE HTTP SERVER]: Slow handling of 498 POST /CAPS/ ......
took 5708ms
22:16:05 - [BASE HTTP SERVER]: Slow handling of 505 POST /CAPS/ ......
took 4644ms
22:17:35 - [FORMS]: Slow request 45 POST ........ took 100125ms,
23:19:17 - [FORMS]: Slow request 138 POST....... took 100024ms,
23:19:58 - [USER AGENT CONNECTOR]: Unable to contact remote server
...... for GetServerURLs
Region (root) # Stacktrace:
Native stacktrace:
mono() [0x498a19]
mono() [0x4e999f]
mono() [0x41f617]
/lib64/libpthread.so.0(+0xf140) [0x7effa5a6c140]
mono() [0x5e04d9]
mono() [0x5dd4a0]
mono() [0x5e0cfc]
mono() [0x5e15d2]
mono() [0x5e1c07]
mono() [0x5e263d]
mono() [0x5dc292]
mono() [0x5dc575]
mono() [0x5dc7ee]
mono(mono_array_new_specific+0xe2) [0x590602]
[0x4186fd7d]
Debug info from gdb:
So have done a bit searching, thereare maby a few hints.
I try to explain it best i can, hope 1 of them is direction to the solution.
Its maby more a collection of ideas , more the needle in the hay.
Not C# expert, but what i see the request code is pretty basic.
The one opensim uses looks a bit like whats used on
**********
http://www.codeproject.com/Articles/13486/A-Simple-Crawler-Using-C-Sockets#WebRequest
and look at the section, "2. *WebRequest and WebResponse problems:" *am
quoting a piece of text from that website
""This code works well but it has a very serious problem as the
|WebRequest| class function |GetResponse| locks the access to all other
processes, the |WebRequest| tells the retrieved response as closed, as
in the last line in the previous code. So I noticed that always only one
thread is downloading while others are waiting to |GetResponse|. To
solve this serious problem, I implemented my two classes,
*|MyWebRequest|* and *|MyWebResponse|*.""
**********
HttpWebRequest.GetResponse Method seems to block.
the Microsoft page say the following:
http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse%28v=vs.71%29.aspx
""This method blocks waiting for content to post; if there is no
time-out set and you do not provide content, your application will block
indefinitely.""
**********
Maby the ServicePointManager.Expect100Continue Property is intressting
to use ?
http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.expect100continue%28v=vs.71%29.aspx
**********
last thing that i want to point to is this site
http://stackoverflow.com/questions/2519655/httpwebrequest-is-extremely-slow
The talk about that the http proxy is enabled default, and that disable
it can speed up the process.
Most of the above things come from this page.
=====================================
On 2012-09-22 02:22, Justin Clark-Casey wrote:
There are no timeouts on these particular requests, which probably
isn't a good thing - OpenSimulator is inconsistent when it comes to
timeouts. However, I suspect that's oging to be peripheral to the
issue here.
On 20/09/12 11:44, M.E. Verhagen wrote:
I wonder if there is a timeout on the fetch request ?
Or are they stacking up and just waiting till they are in the front
of the line to be processed ?
2012/9/20 Justin Clark-Casey <[email protected]
<mailto:[email protected]>>
Fetch times of 1068560ms (which is more than 15 minutes!) are
pathological - something is wrong.
In the first case I would suspect an issue with the connection to
the OSGrid inventory service. Either it is being
overloaded (OSGrid actually runs multiple copies of the ROBUST
inventory service and load-balances between them
using Nginx, but perhaps the limits are being hit), things are
being massive lagged because of lots of requests
hitting the .net default connection limit, as Melanie discussed,
or you have a network issue.
However, I'm a little surprised that the OSGrid Inventory Service
request within FetchInventoryDescendents2 isn't
making it's own complaint about a long request. The log message
you're seeing does cover the whole of the CAPs call
so I suppose there is some chance there's some other cause,
though it is a pretty simple capability.
If you want to see if viewers are doing a lot of inventory
fetches, then you can try the command "debug http 3" on
the simulator console. This will show every incoming http
request from viewers (and other simulators) and the HTTP
URI they are hitting. Very recent code also has levels 4 and 5
which will log a snippet of the incoming request and
the entire request, though you probably don't want to use them
for any length of time.
On 14/09/12 11:33, Ai Austin wrote:
From: Melanie <[email protected]
<mailto:[email protected]>>
You're using a viewer that fetches the user inventory in the
background on login. ...
You will need to disable inventory fetch on startup and/or
viewerside AO.
Thanks for the explanation Melanie... that sounds like it is
the type of problem I am seeing on our add on OSGrid
regions... but not on our own Openvue grid whcih essentially
runs on identical hardware and with identical
network setups.
I am observing the problem with both LL 3.3.4 and
Firestorm/Pheonix 4.2.2...
I don't have the viewer provided sAO turned on in Firestorm,
but I just looked at all the settings I can find in LL
3.3.4 and Firestorm 4.2.2 and cannot see one that refers to
http fetching via http. Although I am sure I have
seen this
in the past on earlier viewers. Which Preferences tab is it on?
From: James Stallings II <[email protected]
<mailto:[email protected]>>
I would recommend (assuming firestorm here) setting both
inventory fetch
and texture fetch to http in the settings, and making the
following changes
to opensim.ini:
[ClientStack.LindenCaps]
...
Cap_GetTexture = "localhost"
Cap_GetMesh = "localhost"
; This is disabled by default. Change if you see
fit. Note that
; serving this cap from the simulators may lead to
poor performace.
Cap_FetchInventoryDescendents2 = "localhost"
Cap_FetchInventory2 = "localhost"
Yep, that what I am set to already James.. I just checked.
Thanks.
_________________________________________________
Opensim-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_________________________________________________
Opensim-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.berlios.de/__mailman/listinfo/opensim-users
<https://lists.berlios.de/mailman/listinfo/opensim-users>
--
Groningen en Hannover Opensims:
secondlife://meverhagen.nl:8002:Hannover ZW/
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
