Project Steering Committee - Home

Meeting Info

This meeting of the MapGuide PSC will take place Thursday, May 7, 2009 at 18:00 UTC (2:00 PM ET / noon MT / 11:00 AM PT).

Meeting Chair: Bob Bray

Universal Time: ​http://www.timeanddate.com/worldclock/fixedtime.html?month=5&day=7&year=2009&hour=12&min=0&sec=0&p1=55

Location: The meeting will be held on IRC at ​#mapguide

Agenda

• Appoint a Meeting Secretary
• Available MGOS developers
• voting on RFC60 ​http://trac.osgeo.org/mapguide/wiki/MapGuideRfc60
• commit rights for UV to support configuration management
• Handling of failed tiles ​http://n2.nabble.com/Server-rendering-incomplete-tiles---Defect-or-Feature---td2785311.html
• Approaches to improve error propagation from FDO
• Finding a time for one of the upcoming PSCs where the Australians can participate?

Minutes

PSC Members present: Tom, Bob, Bruce, Andy, Haris.

Review last meeting's action items

• All items are on todays meeting as well

Available MGOS developers

• ??

Voting on RFC60

• Bruce will bring it to a vote.

Commit rights for UV

• Not at this time as the process for being granted commit rights needs to be followed and is not complete.

Handling of failed tiles

• UV volunteered to write an RFC for a solution to this - Tom will ask him.

Approaches to improve error propagation from FDO

• Fix MACROs that are creating new exceptions that lose parent FDO error

Finding a time for one of the upcoming PSCs where the Australians can participate

• Bob will ask on list for a more friendly time

Performance and Stability

• Discussed selection issue
• Haris will investigate further

End of meeting

Full transcript

Known Networks 		ChatZilla error 	Connected Networks 	<none>
URL 	irc://foo/bar 	Not Connected 	Lag 	<unknown>
URL 	irc://irc.freenode.net/mapguide 	Mode 	+tnc 	Users 	9, 1@, 0%, 0+
Topic 	MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/projects/4656 -and- http://cia.navi.cx/stats/project/MapGuide
URL 	irc://foo/bar 	Connected via 	<none>
<none>
<none>
<none> 	Connected to 	<none>
File 		Progress 	<unknown>
 
#mapguide
	[INFO]	Channel view for “#mapguide” opened.
	*NickServ*	Please identify via /msg NickServ identify <password>.
	=-=	User mode for bdechant is now +i
	-->|	YOU (bdechant) have joined #mapguide
	=-=	Topic for #mapguide is “MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/projects/4656 -and- http://cia.navi.cx/stats/project/MapGuide”
	=-=	Topic for #mapguide was set by jasonbirch on Monday, May 28, 2007 12:47:53 PM
	===	#MapGuide http://mapguide.osgeo.org/
	<bdechant>	Hello everyone
	[INFO]	This channel requires that you have registered and identified yourself with the network's nickname registration services (e.g. NickServ). Please see the documentation of this network's nickname registration services that should be found in the MOTD (/motd to display it).
	<rbray>	Hey Bruce, Hi Harris
	<HarisK>	hi
	<tomf2>	Hi, this is Tom
	<rbray>	I am going to give folks another minute
	<rbray>	Alright, well let's start and see if anyone else joins
	<rbray>	Who want's to take minutes today?
	<rbray>	Was that Bruce I heard volunteer?
	<bdechant>	:)
	<bdechant>	Sounds fine Bob
	<rbray>	First item is: Available MGOS developers
	<rbray>	I believe that is Tom's
	<tomf2>	I know of some excellent developers who have done work on MGOS
	<tomf2>	I think that there may be some projects for them, but I'm not sure what or who has them
	<rbray>	So to clarify Tom, these are freelance developers looking for work?
	<tomf2>	I'm wondering if we should set up a page or something that allows these people to contact each other
	<tomf2>	Yes, freelance, that is, they are not Autodesk developers
	<HarisK>	I know 3 of them , counting me :)
	<rbray>	Hmm, I would suggest the wiki
	<rbray>	But don't you need commit rights to edit?
	<tomf2>	Anyone can edit the wiki
	<tomf2>	you just need a trac login
	<tomf2>	I think
	<HarisK>	wiki page would be to make list of available MGOS developers, to present themselves ?
	<tomf2>	Yes, that was what I was thinking
	<tomf2>	If we're OK with that, I could look around at some other projects and see if they are doing anything similar, and perhaps use that as a model.
	<HarisK>	sounds fine
	<rbray>	Makes sense to me
	<tomf2>	Great
	<rbray>	They could also introduce themselves on the internals mail list
	<tomf2>	good idea
	<rbray>	Anyone disagree with having a wiki page for freelance developers?
	<rbray>	ok then, Tom you have the action to create a wiki page for that
	<tomf2>	Ok
	<rbray>	Next item: voting on RFC60
	<tomf2>	I think the next items are either Zac's or UV's
	<rbray>	Well for RFC60, if we think it is ready to vote - then a PSC member just needs to put it for a vote on the mail list
	<rbray>	UV can't bring it forward for a vote because he is not a PSC member
	<tomf2>	Has it been put out for review? I can't recall
	<rbray>	yes it has had lots of feedback
	<tomf2>	bdechant, could you put it out for vote if no one else volunteers?
	<bdechant>	sure :)
	<HarisK>	I cant remmber discussion arround, rfc allone
	<HarisK>	more about some problems beign found
	<bdechant>	that is the latest I recall too
	<rbray>	well according to UV's last e-mail the patch is ready for review and to submit
	<bdechant>	May I suggest that you look it over today and if no one comments I can post for a vote tomorrow
	<tomf2>	We can also look over it during the vote and reject if we see problems
	<tomf2>	That's only 48hours though as opposed to 7 days
	<rbray>	either is fine, I looked at it today and it seems like he has already addressed a number of issues that folks raised
	<tomf2>	So my vote is to go directly to vote.
	<rbray>	Mine too
	<bdechant>	ok I'll call for a vote today
	<rbray>	ok
	<rbray>	thanks
	<rbray>	The next item is this one: commit rights for UV to support configuration management
	<tomf2>	+1
	<rbray>	really?
	<rbray>	I have two concerns:
	<rbray>	What code has he submitted so far and who has reviewed it - I'd like their input
	<rbray>	Some of his comments on the list have been inflamitory
	<rbray>	Any reactions?
	<bdechant>	I agree
	<rbray>	To the later I presume
	<rbray>	Anyone know the answer to the first
	<rbray>	GEnerally I'd like to see at least a couple of submissions
	<bdechant>	I have not reviewed his code submission so cannot comment on that
	<tomf2>	I thought that configuration management is not part of the main code stream, like the installer stuff is, but actually it is all the project files and build files, and these are pretty central. My mistake. This is a pretty importanta area
	<HarisK>	Bob , that is good point, to get some working results
	<tomf2>	Patch files should be the appropriate process for this
	<rbray>	Yes I would like to see a few patches
	<tomf2>	I mean, use our normal process of submitting patches first, then getting commit rights
	<bdechant>	I would like to see a few patches 1st before commit rights
	<rbray>	Well that is the way the process of adding developers is documented - proven track record, recommendation, vote
	<rbray>	So let's put that one off for now
	<bdechant>	Yup and that is what I would for us to use :)
	<bdechant>	*like
	<rbray>	Ok next item: Handling of failed tiles http://n2.nabble.com/Server-rendering-incomplete-tiles---Defect-or-Feature---td2785311.html
	<rbray>	What's the background on this?
	<bdechant>	Essentially the stylizer eats any exception it encounters
	<bdechant>	No feedback ir given to the user, an error is logged and that is it
	<tomf2>	Looks like someone would need to put an RFC together on how to resolve this, then we could go from there
	<bdechant>	Agree as this is more then a simple defect fix
	<rbray>	Yes I guess we need a proposal for alternate behavior
	<rbray>	and some discussion around what the "right" behavior is
	<tomf2>	Yes, looking at that discussion, there are different possible solutions for different scenarios
	<tomf2>	Towards the end UV asks if he should put an RFC together for this. So I'll reply and say yes.
	<rbray>	Ok - sounds like a plan.
	<HarisK>	I believe I dont agree with posiblle resolution from email
	<HarisK>	but +1 for writting rfc
	<rbray>	yes let's see if UV will submit an RFC - then we will have something to discuss
	<rbray>	ok
	<rbray>	How about this one: Approaches to improve error propagation from FDO
	<rbray>	Anyone know what this is about?
	<tomf2>	no
	<HarisK>	I sen email day or two ago on internal list, about FDO error not going into MG log
	<HarisK>	unhandled exception goes in
	<bdechant>	From what I understand this has to do with propogating up the underlying error along with the FDO error
	<HarisK>	if that is the topic, then it is more a smaller defect/bug from what i saw
	<bdechant>	So being able to see the parent error along with the FDO wrapper error
	<HarisK>	it goes as unhadled instead of fdo error
	<HarisK>	some bug in macros being used i believe
	<bdechant>	several currently do yes
	<HarisK>	it is small issue in code I think, but could help a lot sometimes to see correct message in log file
	<bdechant>	I think this is more of an FDO issue as MG already catches and logs them
	<HarisK>	hm I think not
	<bdechant>	Explain?
	<HarisK>	ther is one macro which caches FDO exception and then throws unknown MG exception
	<HarisK>	I posted that in email ,just a sec
	<bdechant>	Actually there are severla macors that are used, some of hte Unclassified ones are a result of FDO not throwing an exception at all
	<HarisK>	#define RSFR_CATCH() } \
	<HarisK>	catch (MgException* ex) \
	<HarisK>	{ \
	<HarisK>	ex->Release(); \
	<HarisK>	throw FdoException::Create();\
	<HarisK>	}
	<HarisK>	after this originall FDO messages gets lost
	<bdechant>	That one is bad and needs to be fixed
	<HarisK>	:)
	<HarisK>	and couple more
	<bdechant>	I think we are talking about 2 issues here then
	<HarisK>	but yes, it is not big task
	<bdechant>	1) Macros need to be fixed
	<rbray>	Seems like we should just fix this
	<bdechant>	2) Internal error codes from underlying RDBMs are not being propogated up via FDO
	<bdechant>	If we are talking about #1 then ignore my other comments as I was assuming #2
	<rbray>	we should fix #1
	<rbray>	and raise the second to the FDO PSC
	<bdechant>	For MapGuide - I agree #1 needs to be fixed
	<HarisK>	I was not aware about 2
	<HarisK>	agree,s to FDO list
	<rbray>	Ok everyone I need to wrap up as I have another meeting
	<bdechant>	I beleive #2 will be raised at the next FDO PSC (From those I have talked to(
	<tomf2>	Those internal error codes are data source specific, so how useful would they be.
	<rbray>	I will ask on the list about a more friendly Aussie time for this meeting.
	<HarisK>	ok
	<tomf2>	I'm OK with other times as long as it is not between 10pm and 7am mountain time
	<rbray>	wimp
	<tomf2>	OK, 10:30pm and 7am
	<bdechant>	:)
	<HarisK>	next topic: perfomance and stability ?
	<HarisK>	:)
	<rbray>	You guys can keep talking - I think that is a good topic
	<rbray>	But I have to run
	<tomf2>	I'm interested in that, can you stick around Harris?
	<HarisK>	we are having hard time on couple of projects
	<HarisK>	yes great
	<tomf2>	What are you finding?
	<rbray>	ok guys - thanks
	<tomf2>	OK, thanks Bob, bye
	<HarisK>	thanks Bob
	<HarisK>	we have problems with both speed and performnace
	<HarisK>	we tried to use Fusion also
	<HarisK>	it was not good from current release
	<tomf2>	What providers are you using?
	<bdechant>	Can you describe the user scenario?
	<HarisK>	after applying all trunk stuff
	<tomf2>	current release = MGOS 2.1?
	<HarisK>	it is almost usable but stil... not satisfactory
	<HarisK>	yes
	<HarisK>	2.1
	<HarisK>	in general, it is quite a few issues
	<HarisK>	speed is still slow
	<HarisK>	we dont use tiles
	<HarisK>	also stability, we have problems with multiple users
	<HarisK>	still trying to understand where problem is
	<bdechant>	For slow - are you referring to rendering map, selection, something else?
	<HarisK>	I am also loooking at King.Oracle and MapGuide
	<HarisK>	it seems something with selection
	<bdechant>	About how many items are being selected?
	<HarisK>	selection was very bad with some of current releases of Fusion
	<HarisK>	it got improved a bit
	<HarisK>	It is hard to talk light this, we would need to get some numbers
	<HarisK>	I mean, hard to tell where really time is lost
	<HarisK>	overall experience is not good
	<HarisK>	not much, 10-15 items
	<bdechant>	There is an issue when selecting thousands of features
	<HarisK>	map is about 50 layers
	<tomf2>	Selection is much more responsive in Fusion, we draw the selection first, then asynchronously populate the properties panel. So it should seem more responsive because the user sees the selection quickly. Also, there was a lot of work to improve the performance of getting the property values back from the server.
	<HarisK>	what is issue with selection ?
	<bdechant>	Very slow with lots of features
	<HarisK>	I have started to think that function Renderforselection could have some multithreading issues too
	<bdechant>	I haven't seen this with small #s
	<HarisK>	we are getting MG crashed with several select requests, don't know why yet
	<bdechant>	ouch - what providers involved?
	<HarisK>	yes speed of selection is much better now
	<HarisK>	but only if you compare it to previous release which was almost unusable
	<HarisK>	King.Oracle
	<HarisK>	I am still looking most intop provider itself for reason
	<bdechant>	Would it be possible for you to send me a package that I could play with?
	<tomf2>	A selection with a 50 layer map should display on the screen within a second (well, that's what we see in MG Enterprise)
	<HarisK>	but can't find anything yet (we spend a almost week on it)
	<bdechant>	Have you tried replicating the crash with SDF/SHP/MySQL?
	<HarisK>	unfortunately not
	<HarisK>	we have this layers on customer site
	<tomf2>	How many seconds are you seeing?
	<HarisK>	with some Orcqel links and ESB bus etc..
	<HarisK>	Oracle
	<HarisK>	no crash with SDF with some of data
	<bdechant>	What about trying the Autodesk ORacle provider?
	<HarisK>	hm, cant tell seconds exactly
	<HarisK>	yes, we could try that too ( if he can suport views now)
	<tomf2>	yes, Autodesk Oracle provider supports views
	<HarisK>	overall experience is not good for our customers ( and we are not either)
	<tomf2>	It might be the new DescribeSchema work that speeds things up. Testing using the Autodesk Oracle provider could help us see
	<HarisK>	it is not provider itself or schema for speed
	<HarisK>	schema is cached and data is retrieved quickly enough, that i could meassure
	<tomf2>	The new describeSchema support really shrinks the size of the schema that the server needs to maintain
	<HarisK>	one of things, I see now I believe even more requests generated to MG from Fusion
	<tomf2>	Getting the schema might be fast, but if it is a large object, the server might have trouble maintaining it
	<HarisK>	schema is cached in provider so it is just initall load which takes a bit longer
	<tomf2>	The new fusion should have 50% less requests than the 2.0 version
	<HarisK>	Fusion 2.0 yes
	<HarisK>	I mean, I assume that yes
	<HarisK>	but still
	<tomf2>	Right, but the server needs to pass the schema around; for example to the web tier. Smaller is better
	<HarisK>	compared to ajax viewer or ...
	<HarisK>	we have same speed feeling with sdf
	<HarisK>	it even feels slower in multiple users environment
	<tomf2>	How many classes in the SDF schema
	<HarisK>	4-5
	<HarisK>	the one we used for selection test
	<tomf2>	Oh, that's not many at all
	<HarisK>	no, it is not
	<HarisK>	I don't think there is quick solution
	<bdechant>	Seems like very little schema information
	<HarisK>	but I do think that really but really :)
	<HarisK>	performance and stability should be priority
	<tomf2>	Bruce, you asked for a package earlier, how about testing with the SDF?
	<tomf2>	yes, performance and stability are always a priority
	<bdechant>	Either would be fine - I just want to see what is happening in the debugger for selection in this case
	<HarisK>	I know we always talk about hose two
	<HarisK>	but somehow, it seems slower and less stable then 1.2
	<HarisK>	I know, we could just be a bit frustrated right now
	<bdechant>	that seems odd and we need to get to the bottom of it
	<HarisK>	one of things I would like to know
	<HarisK>	where time is really lost
	<tomf2>	The way we work is to fix things that we know about. It probably just means we haven't run into what you are seeing right now.
	<HarisK>	to have some type of test tool, to try to seperate rendering part, web part, etc..
	<HarisK>	you are satisfied with the speed ?
	<bdechant>	For some things yes - for others no
	<HarisK>	:)
	<tomf2>	For a sub second select, yes. But if you are seeing selection taking 20 seconds no; but like I said, we don't see that
	<bdechant>	There is always room for improvement :)
	<HarisK>	you are in politic too ? :)
	<HarisK>	I just feel that something radical/serious should be done to get it much better
	<tomf2>	You think there is a fundamental flaw in the architecture that will prevent something from being responsive?
	<HarisK>	I was even thingik to get stylization "out" to see how fast just rendering wotks
	<tomf2>	rendering is fast, I don't think that you will find anything there
	<HarisK>	fundamental flaw ? hm no
	<HarisK>	perhaps services over tcp/ip
	<tomf2>	It seems that most of the problems are in the support of rendering
	<bdechant>	I think some timing hooks could be added so that when doing some of the advanced trace logging you could see some of the server's internal #s
	<HarisK>	what about getting rendering and feature access directly into web part ?
	<bdechant>	that would be one of the more radical suggestions :)
	<HarisK>	:)
	<HarisK>	I looked a worked a lot with MG code lately, I do have feeling that some parts are
	<bdechant>	I don't think that is the bottleneck though
	<HarisK>	very how to say "nice", nice classes calls etc..
	<HarisK>	but sometimes it looks , I don't know how to express, "overdone" in nice
	<HarisK>	I dont know if you can understand me
	<bdechant>	Ohh I know what you mean - there is some code that could be much more efficent while still being clean and well presented
	<HarisK>	yes
	<tomf2>	Sometimes dirty code is required for optimizations, but we need to find out where those parts are first
	<tomf2>	Do you have access to code profilers such as GlowCode or Visual Studio Team Editon or Intel VTune etc.?
	<HarisK>	hm no, I grew in area of no debuggers :)
	<tomf2>	The team here uses them and they are very useful; and of course you can't just use one because they all give different answers.
	<bdechant>	They can also generates lots of noise that needs t obe filtered out :)
	<tomf2>	I have to go now. It looks like there is a specific problem that Bruce is interested in seeing; selection using a particular DS. If you could get him that package, that would be great!
	<tomf2>	DS = data source
	<HarisK>	thank you, I will try
	<HarisK>	I will try to spare bruce time too
	<HarisK>	if we dont find reaso by monday next week, i will contact you again
	<bdechant>	Sounds good
	<bdechant>	So meeting over then - thanks all
	<HarisK>	thank you for listening me