Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005293opensim[REGION] OpenSim Corepublic2010-12-29 12:072011-01-04 09:40
ReporterMyanThor 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0005293: DataSnapshotProvider reports parcels only on the first region
DescriptionIf one Opensim intance serves multiple regions then DataSnapshotProvider reports parcels for the first region in regions.ini only.
Additional InformationEvery region have a default parcel named "Your Parcel". But http://regionhost:9000/?method=collector [^] dont show them except for the first region. Objects that are set to show in search are reported for all regions.

Example: http://tausys.servegame.com:9000/?method=collector [^]
TagsNo tags attached.
Git Revision or version numberr14726
Run Mode Grid (1 Region per Sim)
Physics EngineODE
Script Engine
Environment.NET / Windows64
Mono VersionNone
Viewer
Attached Files

- Relationships

-  Notes
(0017704)
samiam (reporter)
2010-12-31 07:58
edited on: 2010-12-31 10:46

Yes i see this as well, found i needed to edit the database ossearch hosts field.
Changed the FQDN to the LAN ip (let it register normaly 1st).
Then when all instances have registered and each FQDN is changed then change the call to register.php to call parser.php insted. (trick i found that makes it so i dont need a cron event).The resion to disable register.php call is so that it dosent re-register them again. It will add it in as new instance with the FQDN again (messy).
If you add more instances you would need to re-enable it again so it can register but if you dont add more then this works well.
All things set in search incl landsales will show up as they should.
Im not shure what the problem is that it dosent translate the FQDN to LAN IP# but thats the workaround i used that holds up ok.
(it gets the host info from whats set in the region.ini and you cant use LAN IP there or web cleints cant connect to it).

tnx

The table that has the host field is in ossearch.hostsregister, the others are ok.

(0017705)
samiam (reporter)
2010-12-31 08:12

SubNote: Seems also that datasnapshot no longer triggers as a timed event. It does trigger on instance shutdown though. This should be fixed so it will run the sanpshot as inteneded.

Tnx
(0017706)
samiam (reporter)
2010-12-31 12:22

I have looked into the code a bit on both sides to see what could be done but its quite complex. There are many other things that depend on the way it works and dosent seem trivial to hack something in.
At one point using lan IP's in region ini dident effect remote web clients abuility to connect and at the same time all this worked without issues.
(Routers port fwd And ROBUST took care of this fine).
Last knowen good was 08/15/2010 (.7x series) but alot has changed from then till now.
If it wasent for this issue i wouldent have been able to trace it out.
I havent tryed using web IP in the regions ini but i expect the same problem is there to. Not everyone has a dynamic IP so FQDN is nessary when web ip's are changed.
A few thoughts may be to use other region ini (local ip) rather than the main.
this may give the proper trnsalation of FQDN to Lan ip. I have tryed that but it only uses the primary not the local ip.
The resion i havent chimed in on this b4 is because it lies in gray area between core code and 3rd party.
The answer is there but both sides need to adj a few things.
The other way would be id have to force reverse dns lookup to TRICK it somehow, thats a worse solution though.

Usualy i wouldent make a fuss here but as search is the root of other functions that use its results, this matters to many other things not just search.

We spent many (CP's) to find the root of the evil.
(CP=Coffee Pots) and on a scale of 10CP's this was a 3.5 :)

tnx
(0017733)
MyanThor (reporter)
2011-01-02 05:43

After some looking into the code I have found the problem: missconfiguration on my side. After setting "data_exposure = all" DataSnapshotProvider works as expected.

Should I set this ticket as resolved because an other problem has been appended?
(0017758)
samiam (reporter)
2011-01-04 09:40
edited on: 2011-01-04 10:49

It is a few problems in one. What happens is now that it has some data on the primary region it tends to not update as things are added or changed. So it keeps reading the old data. (even if parser fires) Also it will ignore regions that are in the same instance but not on the inital listning port#. It will aquire data of all regions if i make the instance that registers (lan ip) and not FQDN.
I think there are sub issues that will continue to haunt it.
The update (datasnapshot event) Is somewhat of a sep. problem but can cause alot of head scratching and seems like part of the issue you reported here.
The other problem of FQDN vrs LAN IP has the same effect as you have reported here. They both use the same search system in order to work right.
Might want to leave this open a bit longer, others are looking at some of these things and using this for a ref atm.
I think the timed snapshot event has already been reported elsewhere.
If all that is fixed in core is the timmed snapshot, that will help.

(fixed typos)
tnx


- Issue History
Date Modified Username Field Change
2010-12-29 12:07 MyanThor New Issue
2010-12-29 12:07 MyanThor Git Revision => r14726
2010-12-29 12:07 MyanThor SVN Revision => 0
2010-12-29 12:07 MyanThor Run Mode => Grid (1 Region per Sim)
2010-12-29 12:07 MyanThor Physics Engine => ODE
2010-12-29 12:07 MyanThor Environment => .NET / Windows64
2010-12-29 12:07 MyanThor Mono Version => None
2010-12-31 07:58 samiam Note Added: 0017704
2010-12-31 08:12 samiam Note Added: 0017705
2010-12-31 08:47 samiam Note Edited: 0017704
2010-12-31 10:46 samiam Note Edited: 0017704
2010-12-31 12:22 samiam Note Added: 0017706
2011-01-02 05:43 MyanThor Note Added: 0017733
2011-01-04 09:40 samiam Note Added: 0017758
2011-01-04 10:49 samiam Note Edited: 0017758


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker