Project Steering Committee - Home

Meeting Info

This meeting of the MapGuide PSC will take place Thursday, April 2, 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=4&day=2&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
• Updates on Actions from the Last Meeting
• Status of the PayPal initiative for builds (added by Tom)
• 2.1 branch (including setting externals to CS-Map 12.01 branch) (first part of this added by Tom)
• If Paul is here, timeline for next Fusion 2.0 beta?
• Way forward on Raster for 2.1
• Others?

Minutes

PSC Members present: Tom, Bob, Bruce, Jason, Haris, Kenneth.

Review last meeting's action items

PSC Members present: Tom, Bob, Bruce, Jason, Haris, Kenneth

Review last meeting's action items

• All items are on todays meeting as well

Status for the PayPal initiative

• There are legal issues involved, since Trevor is an Autodesk employee.
• An outcome is expected before the next meeting.

2.1 and CS-MAP

• Trunk should point to CS-MAP 12.01
• Branches are not created until a specific major code change is expected
• ... And a special case is the MG Connection Manager patches that Haris proposes.
• Tom will assist Haris in setting up the branch, and Bruce agreed to work on the issue with changes.

Fusio 2.0 beta timeline

• Likely to be ready Monday

Raster issues for 2.1

• Debate on what locks are required
• Suggestion:
  • Add the two fixes produced by Haris (already commited)
  • Add the stylization lock produced by Haris
• Votes: Tom +1, Bob +1, Bruce +1, Paul +1, Kenneth +1
• Postpone the refcount fix produced by Traian, and initially suggested by Haris due to possible issues with the lock

End of meeting

Full transcript

[INFO]	Channel view for “#mapguide” opened.
	<rbray>	Hey everyone, are we ready to start?
	<tomf2>	I'm ready
	<bdechant>	Same
	<ksgeograf>	ready.
	<rbray>	Who want's to take minutes today - any volunteers?
	<ksgeograf>	I would like to give it a try today
	<bdechant>	I will volunteer
	<ksgeograf>	I'll step down then :)
	<bdechant>	you sure? :)
	<rbray>	Ok, Kenneth it is
	<rbray>	I checked last meetings minutes and there really are no actions with updates that are not in this weeks agenda already - so let's start there
	<HarisK>	hi
	<rbray>	So first item: Status of the PayPal initiative for builds
	<rbray>	Tom this is yours
	<tomf2>	We are currently trying to figure out whether Trevor is allowed to do this as an employee of Autodesk
	<tomf2>	I was hoping to have a better update today, but
	<tomf2>	the meeting with the lawyers did not go through yesterday as planned. So we will have to wait some more
	<tomf2>	That's it. Any questions?
	<rbray>	Apparently the meeting with legal is monday - I asked Trevor just before the PSC meeting
	<rbray>	So we should know more next week
	<rbray>	I appologize for the delay on this, everything legal here takes a while
	<rbray>	Anyway, next item: 2.1 branch (including setting externals to CS-Map 12.01 branch)
	<jasonbirch>	oops; sorry
	<tomf2>	I'm wondering whether anyone is holding onto a big submission for branch, but they can't because we haven't created the branch yet
	<tomf2>	I mean for trunk
	<tomf2>	...but maybe we are at the stage where it would be good to create the branch anyway
	<jasonbirch>	My main thing about getting a branch
	<jasonbirch>	Is that then we could hard-code specific tags for externals
	<jasonbirch>	Like for CS-Map
	<jasonbirch>	Instead of following their trunk
	<tomf2>	We've always been holding off on creating branches because it saves developers some time if they don't have to merge. I'm good with pointing to CSMap 12.01 even from Trunk
	<jasonbirch>	OK, I'd be OK with that too.
	<jasonbirch>	We don't really have to branch until
	<jasonbirch>	we start getting people wanting to make massive chances
	<jasonbirch>	Or release, whatever comes first :)
	<jasonbirch>	chances -> changes
	<tomf2>	OK, just say when you want the branch and I'll make it. I'll also make that change to point to CSMap 12.01 today.
	<bdechant>	thanks Tom
	<rbray>	ok next item
	<HarisK>	If I would sumbit changes for MG connection manager, that would require branch to submit too ?
	<rbray>	Oops - hold on
	<HarisK>	sorry, Bob slow here
	<rbray>	Thats ok
	<jasonbirch>	If you were going to change connection manager to not use refcounting
	<jasonbirch>	I think that someone wanted that do be done in a post-2.1
	<jasonbirch>	Bruce maybe?
	<bdechant>	that was me Jason :)
	<bdechant>	The connection manager code is a vital part of MapGuide and changing it this close to release could be dangerous
	<HarisK>	agrre, only I would like to understand if I would like to change it
	<rbray>	How big is the change?
	<HarisK>	not so big in coding
	<HarisK>	but may effect all parts of MG as Bruce said
	<rbray>	I think we should assess the risk - maybe via code review
	<rbray>	and then decide
	<bdechant>	agree
	<jasonbirch>	I guess we're still counting on the ADSK beta to give us some stability, and not relying on our own Beta process very much. That will have to change eventually.
	<jasonbirch>	We're not tehnically all that close to release is all I mean :)
	<HarisK>	agree, to do review I would ask fro branch and do changes there ?
	<rbray>	That is why I think we should look at it
	<rbray>	HarisK - can you make a patch?
	<jasonbirch>	HarisK: Someone could create a sandbox for you
	<jasonbirch>	to work in.
	<tomf2>	There is a sandbox area, HarisK your change seems more appropriate for that
	<HarisK>	ok
	<tomf2>	It seems that you are doing a proof of concept type exercise; please correct me if I'm wrong
	<HarisK>	I hope not :)
	<HarisK>	connection manager is not working properly in MG
	<jasonbirch>	If more than a couple files have to change, then a sandbox is better than patch anyway (I think)
	<jasonbirch>	And a patch can easily be generated via SVN once the changes are made and tested in sandbox.
	<HarisK>	and not a proof concept but try to make it work
	<jasonbirch>	If the changes aren't too risky, it would be nice.
	<tomf2>	Couldn't you do that all locally? Why do you need a branch for this?
	<jasonbirch>	He could, but then would have to upload patch for review.
	<jasonbirch>	Also, local changes don't get backed up :)
	<ksgeograf>	He needs a branch for review purposes
	<tomf2>	Reviews can be done via patches
	<jasonbirch>	So if he's doing a lot of work, would be better to do it in a branch.
	<jasonbirch>	The sandbox can easily be deleted post-work
	<tomf2>	yes, if it's a lot of work a branch would be good
	<tomf2>	That's a good reason
	<bdechant>	I think sandbox is right place to do this
	<tomf2>	BTW, HarisK, thanks for doing this. Do you need any help creating the branch?
	<HarisK>	yes, i would need help with svn in any case, thanks
	<tomf2>	OK, I'll create you a sandbox/haris/2.1 branch
	<tomf2>	(feel free to give me a different name)
	<HarisK>	ok, I was also waiting when 2.1 will roll out
	<rbray>	Anything else on this?
	<HarisK>	and chekc with others when would be appropriate time to start this bigger change
	<HarisK>	I am done :)
	<tomf2>	Is there any reason not to start the change now?
	<HarisK>	I was kind of hopping that sombody who was working on current connection manager
	<HarisK>	will come to email list
	<HarisK>	and we discuss it
	<tomf2>	I think that person would be Bruce
	<bdechant>	that is me :) I've started to look at the code
	<jasonbirch>	How about you commit what you have to sandbox so people can see,
	<jasonbirch>	And then discuss? :)
	<HarisK>	it is not only code which i wrote
	<HarisK>	but will need also little bit of changes
	<bdechant>	I'm well aware of the issue and would love to get rid of the reference count tracking
	<HarisK>	which would influence perhaps fewer places of MG code
	<HarisK>	ok, great
	<HarisK>	I would like that we exchange ideas how to solve it, before writting full imp[lementtation
	<bdechant>	I would happy to work with you on this in the sandbox :)
	<bdechant>	sounds good
	<HarisK>	sounds perfect to me
	<bdechant>	we can finish this issue chat offline so we can contiune
	<rbray>	IMO - it would be great to get that in for 2.1
	<rbray>	So let's see how it shapes up
	<bdechant>	we can try :)
	<rbray>	Next item was: timeline for next Fusion 2.0 beta?
	<rbray>	But no Paul today
	<jasonbirch>	next beta?
	<rbray>	Anyone else know the status?
	-->|	pagameba has joined #mapguide
	<ksgeograf>	:)
	<jasonbirch>	lol
	<jasonbirch>	pagameba: ?
	<tomf2>	not bad timing
	<jasonbirch>	your ears ringing?
	<pagameba>	hola!
	<pagameba>	sorry, was in a meeting and lost track of time
	<pagameba>	:D
	<pagameba>	burning more like
	<HarisK>	agile development
	<jasonbirch>	So, Fusion 2.0 beta next?
	<jasonbirch>	when?
	<pagameba>	zjames was eavesdropping for me
	<pagameba>	um
	<pagameba>	hang on ... lemme ask madair what his plans are
	<jasonbirch>	pagameba: he said on list he wanted to fix http://trac.osgeo.org/fusion/ticket/238 first
	<pagameba>	looking
	<pagameba>	oh right - we talked about it
	<pagameba>	yes, we want to fix that first
	<pagameba>	but we could do another beta right after
	<pagameba>	I won't be able to work on it until tomorrow
	<pagameba>	so earliest would be tomorrow or perhaps monday
	<rbray>	ok - thanks for joining Paul and for the update
	<jasonbirch>	pagameba: I don't want to push. I could just point at trunk when building test installers
	<jasonbirch>	Modify my working copy externals, update, etc...
	<pagameba>	I guess although theoretically trunk could get changes that aren't going into 2.0
	<pagameba>	I'd rather we be more thorough in keeping 2.0 current
	<jasonbirch>	That would be cool :)
	<jasonbirch>	IS OL 2.8 going into 2.0? :)
	<pagameba>	yes, I think so
	<pagameba>	Mike has OL trunk in 2.0
	<jasonbirch>	That's cool. Guess I'm going too OT :)
	<pagameba>	which is basically 2.8
	<jasonbirch>	Next topic?
	<rbray>	Sure - everyones favorite. Raster
	<rbray>	There was some more mail on that today I think
	<rbray>	Personally I'd like to see Traian's approach tested, as that change is more scalable than one big lock
	<HarisK>	I think we need to decide for 2.1
	<Traian_>	Hi, for 2.1, just ship the lock
	<Traian_>	people seem to like the lock
	<rbray>	Well maybe everyone but me :)
	<jasonbirch>	rbray, I worry about that. Primarily because the only reason we started with locks in FDOGDAL, and single pool in MapGuide was multithreading instability in GDAL
	<ksgeograf>	I have a few machines that I can load test on, if I get some pathed dll's
	<Traian_>	You guys are trying to fix a refcounting bug with locks -- it's not right.
	<HarisK>	I really think we need to understand problems and divide them
	<HarisK>	no we are not
	<ksgeograf>	I don't have time to build a 2.0.2 from scratch, then patch, but I can test with a prebuilt dll set
	<jasonbirch>	If we can get the non-reference-counted connection manager into 2.1, then we can do away with the lock and allow users to choose between threaded and non-threaded providers.
	<rbray>	It really requires two things I think
	<HarisK>	connection manager is something wrong
	<rbray>	One is the connection manager changes
	<HarisK>	another story is if gdal can support multithreading
	<HarisK>	we cant mix that in
	<rbray>	true - that is the other
	<HarisK>	if/when it will support we will remove locks from fdo gdal
	<Traian_>	Even if you ignore the multithreading part of GDAL, there is still a refcounting problem, that is causing behavior that is different from that of other providers.
	<jasonbirch>	Traian_: is refcounting part of the FDO contract though?
	<HarisK>	it seems not all
	<rbray>	That should be fixed
	<HarisK>	I would assume ADSK raster too
	<HarisK>	and I think i saw one more provider with it
	<bdechant>	no ADSK raster doesn't have the same issue
	<HarisK>	but regardless
	<HarisK>	it chrashes same way with rasters
	<HarisK>	but it is not point anyhow
	<Traian_>	The feature reader in the GDAL provider needs a strong reference to the connection, since it needs the connection.
	<HarisK>	yes, I worte that in my first email
	<HarisK>	but
	<Traian_>	It's the same for the feature reader in SDF or SHP or whatever
	<HarisK>	also fdo client as MG
	<HarisK>	can't get object from connection,close connection and use object
	<pagameba>	is there anything wrong with putting both in?
	<Traian_>	If that bug is fixed, then you don't need the lock in the stylization code.
	<rbray>	Um...not sure I agree Harris
	<Traian_>	There is nothing wrong with putting both in.
	<HarisK>	with both it will lock
	<Traian_>	That's why I said, just ship with the lock, if users want it.
	<rbray>	If an object needs another for it to be valid, then it should hold a strong reference to it
	<HarisK>	there is no library of db
	<HarisK>	hich will allow you to close connection
	<HarisK>	and read from connection
	<HarisK>	but we are talking abut something which is not the reall issue/ not reall cause of problem
	<rbray>	I agree with that too, Ideally the reader would hold a strong reference to the connection
	<ksgeograf>	If there is time pressure, I'm pro shipping with a lock, but if there is a possibility to test a lock free solution that would be nicer
	<rbray>	if the connection is closed, the readeer should return an error
	<Traian_>	There is not a big performance difference between lock and no lock in practice -- I tried it, at least on a dual core machine.
	<HarisK>	btw, it is not even reader
	<rbray>	But that is not the way any of the providers are currently implemented
	<HarisK>	but a raster object returned
	<HarisK>	I played with gdal a year or so ago
	<HarisK>	there were problems with it
	<rbray>	Makes no difference - same logic should apply regardless of the object
	<HarisK>	Frank added lock on every gdal call in provider
	<HarisK>	i would not now unlock that until we have solve MG issues and then really look at gdal multithreading capabillities
	<Traian_>	Yes, even with the lock you get the crash, as I said, you can't fix a refcounting problem with locks. You can repro the problem from a single thread too.
	<HarisK>	and also reall gains in prfoamnce from that part
	<rbray>	Gee - thanks Walt!
	<HarisK>	yes, closing connection and resuing object from it will crash
	<rbray>	Seems the order of things should be:
	<HarisK>	there were 3 probems with MG 2.1 rasters
	<HarisK>	1. memory leak 2. unalloacted pointer use
	<HarisK>	and 3. this connection manager problem
	<rbray>	Evaluate teh connection manager issues, if we fix, then decide what to do here
	<jasonbirch>	rbray, agreed
	<HarisK>	we cant fix connection manager for 2.1 ( two weks)
	<rbray>	If we don't fix the connection manager, then let's just ship with the big freaking lock
	<jasonbirch>	2.1 doesn't have to be in two weeks.
	<HarisK>	not, fix
	<HarisK>	change
	<rbray>	and the difference between fix and change is?
	<Traian_>	Can we also fix the refcounting in the provider? It can't hurt.
	<HarisK>	yes, ofcourse
	<bdechant>	I would like to do both - the strong reference in the reader of GDAL and the FDO connection manager
	<HarisK>	:) I really wrote in email that I want to change that
	<HarisK>	and in my code I did
	<HarisK>	just it is not the main issue to solve
	<ksgeograf>	Traian: your fix is only for the provider, not anything in the server code?
	<Traian_>	Yes, provider only, but with the fix, you can potentially use the provider without pooling connections to it, since connecting becomes pretty fast.
	<Traian_>	Thus bypassing the whole connection pool thing in theory...
	<HarisK>	I believe it will come to
	<HarisK>	unable to create new connections
	<ksgeograf>	So your fix will only introduce a new gdalprovider.dll ?
	<Traian_>	Yes, you can get to that, in my tests it does, and then it waits a bit and then it can create new ones.
	<Traian_>	In my code, I also removed the locks from the MG stylization code, and messed with serverconfig.ini.
	<Traian_>	The real change is in the provider though...
	<rbray>	And what results did you get from your tests Traian?
	<ksgeograf>	So, if only the provider is updated, it gets stable, but has issues in long runs?
	<Traian_>	I am in favor with shipping with the lock, since I get a suspcious thing with FDO XML parsing, which happens when you open connections concurrently. I have not had time to debug this, but I think it happens any time FDO parses XML.
	<Traian_>	It affects all providers which parse XML on open though...
	<Traian_>	The problem with the crash/deadlock disappears in my tests.
	<jasonbirch>	I'd prefer to either fix the connection manager to work properly with single-threaded providers, or ship with the lock, before presenting multithreaded GDAL provider as a testing option for users.
	<jasonbirch>	It had problems in 1.2 when it wasn't constrained
	<jasonbirch>	And I value stability over performance.
	<Traian_>	jasonbirch: may be the problems had to do with refcounting, and not threading :)
	<jasonbirch>	Well, maybe, but we need a stable base to test from.
	<ksgeograf>	If it ships with singlethread setup as default in serverconfig.ini (and it works) I see no issues in allowing users to test multithreading, unless it is known to be unstable
	<Traian_>	Yes, let's just add the global raster lock, but also fix the refcoutning in the provider. We can remove the global lock from the provider itself since it is superceded by the lock in MG.
	<HarisK>	GDAL is allready single threaded
	<HarisK>	Imean fdo gdal
	<HarisK>	perfoamnce is gained on enabling pool for fdo gdal
	<HarisK>	and resuing connections
	<tomf2>	GDAL Provider was made single threaded in a failed attempt to fix the crashing problem wasn't it? So there is no reason for it to be single threaded
	<ksgeograf>	HarisK: if Traian's refcount fix is added to the provider, what is the problems that you see?
	<HarisK>	:)
	<tomf2>	I mean, we eventually want to remove the locks from the GDAL Raster provider, so we shouldn't be doing thigns thatwill assume that it will always be single-threaded
	<HarisK>	It is my suggestion from first email taht provider needs to add ref count as well behaved
	<ksgeograf>	I thought that was what Traians fix does?
	<jasonbirch>	tomf2: what are we doing that assumes single-threaded, other than temporary lock?
	<HarisK>	but only that will lock if we have lock on rasters too
	<Traian_>	I just did what Haris suggested for the provider. It's not something I invented
	<Traian_>	I also removed the locks and sped up connection opening
	<Traian_>	The locks inside the provider will be unnecessary due to the BFL in MapGuide itself
	<HarisK>	schema cache ?
	<Traian_>	BFL = big f-ing lock
	<HarisK>	but we have also other fdo clients
	<tomf2>	jasonbirch: I was concerned about Haris' statement that "GDAL is allready single threaded", so if we do things that assume the slow nature of a single threaded provider we could end up with something that is not as fast as it could be in the future
	<HarisK>	and because we dont know (and i think is not stable) how gdal is safe in mt, i would leave those gdal locks
	<rbray>	We certainly don't want BFL's in all clients
	<ksgeograf>	From here, it looks as if Traian and Haris disagree on the solution, but if Traians patch is what Haris suggested, I'm not following the dicussion...
	<HarisK>	no, not in all clienst
	<HarisK>	other clienst who open connection, use connection, close connection
	<HarisK>	will work
	<jasonbirch>	tomf2: I think maybe terminology difference between single-threaded and per-connection-threaded.
	<Traian_>	My patch is only part of what Haris wants... I claim it's sufficient...
	<Traian_>	This is going nowhere. Here is what I would do this release, you guys take it for what it's worth: 1. Fix refcount in provider, remove lock from provider. 2. Add BFL to MG.
	<jasonbirch>	I'd only want to do that if the changes proposed to the connection manager are not implemented.
	<jasonbirch>	The #2
	<jasonbirch>	The #1 should be done regardless
	<jasonbirch>	I think
	<rbray>	Yep - I agree
	<ksgeograf>	isn't #2 what "CustomConnectionPoolSize=1" means?
	<rbray>	That #1 should be done
	<rbray>	Should be - yes
	<bdechant>	#1 should be done regardless
	<tomf2>	ksgeograf, that's correct, that's what it's supposed to mean, but it didn't work...
	<Traian_>	I'd like #2 for now due to the FDO XML parsing being single-threaded, which gives me a heap corruption every few thousand concurrent requests. I don't think it will happen in real use cases, but until we fix it, I'd keep the lock.
	<HarisK>	remove gdal lock from provider is not right way, I strgly beleiev
	<HarisK>	I dont understand why adding uanother lkevel of uncertainty
	<tomf2>	ksgeograf: perhaps it didn't work because of the refcount problem?
	<HarisK>	we have problem with rasters for very long time
	<HarisK>	why experiment with multithreading gdal
	<ksgeograf>	tomf2: yes, that was what I was thinking
	<rbray>	Perhaps we need to think about this differently
	<jasonbirch>	You guys are guessing; haris tested this fairly thoroughly now, and a year ago.
	<rbray>	Stability is key for 2.1 - yes
	<rbray>	So lets do what we need to do to achieve that, even if there are extra locks we may not need
	<rbray>	For 2.2, we find some time to remove all the freaking locks and look for the real source of hte problem
	<rbray>	You'll never find it with a bunch of irrelevent locks in the way, which mask the problem
	<ksgeograf>	jasonbirch: Does that mean that Haris has found the "CustomConnectionPoolSize" to be faulty, even in the case of correct refcounts?
	<jasonbirch>	ksgeograf: yes
	<jasonbirch>	I think so.
	<jasonbirch>	Haris?
	<tomf2>	jasonbirch: I thought that Haris didn't touch the GDAL Raster provider yet
	<HarisK>	I looked at provider year ago
	<HarisK>	and in last 2 weeks a lot
	<jasonbirch>	tomf2: his proposed fix didn't involve the provlder, but his testing (including this time around) included changes to refcounting.
	<HarisK>	it wasn't easy to find what is exactly going on
	<jasonbirch>	Alone, they didn't fix the problem.
	<Traian_>	What does the patch that people are happy with in the last week contain?
	<tomf2>	HarisK: kenneth and I were wondering if you did the refcounting fix in the GDAL Raster PRovider and then make sure CustomConnectioPoolSize was set to 1 at the same time
	<HarisK>	3 fixes
	<HarisK>	PoolSize doesn pla with GDAL
	<HarisK>	there is fix peace of code in MG, if single threaded then pool size == 1
	<HarisK>	which is also something to change, I believe
	<jasonbirch>	Traian_: that patch contains a fix for the memory leak and invalid allocation, and the big lock. That's all.
	<HarisK>	there were 2 bugs causing unhandled exception when working with rasters
	<Traian_>	so, the only thing that is not checked in yet, is the big lock. Let's add that, and also fix the refcounting in the provider, and call it a day?
	<tomf2>	+1
	<bdechant>	+1
	<rbray>	+1 - for 2.1
	<jasonbirch>	I am concerned that you're looking at 2.2 to fix the connection manager.
	<ksgeograf>	HarisK: does that seem reasonable for you?
	<Traian_>	jason: correct.
	<jasonbirch>	I'm not convinced that the GDAL provider is the only place this problem is manifesting, just the most obvious place.
	<HarisK>	that would need to be tested
	<jasonbirch>	If the work that HarisK is doing is deemed safe enough, I want to see it in the 2.1 branch, if not for the initial 2.1 release.
	<HarisK>	if you add ref count and leave lock it will not work
	<HarisK>	if i remember correctly
	<HarisK>	also, there is allready one lock in stylization code
	<HarisK>	on excecute query
	<Traian_>	So fixing the refcount breaks your fix?
	<pagameba>	+1 for 2.1
	<pagameba>	not that I really understand :)
	<HarisK>	could be, cant remeber this second
	<tomf2>	jasonbirch: so if I have this right, you want to put in some changes that might destabilize the code to fix some problems that we don't know exist (but I agree, probably do somewhere- but may not be caused by the connection manager)
	<jasonbirch>	tomf2: is the code stable? Not my experience...
	<ksgeograf>	+1 for 2.1
	<tomf2>	it doesn't sound right to me, we could put it in a 2.1.1.
	<HarisK>	sorry guys, I am lost in debate now
	<HarisK>	I now what works
	<HarisK>	that is what we sumbited as patches
	<rbray>	So then let's go with that for 2.1
	<HarisK>	all other stuff is something we need to further wok and test
	<ksgeograf>	ok, but it looks to me as if the patches Traian submitted are indeed fixing the refcount problem you describe?
	<HarisK>	there is a huge potential in improving rasters in MG
	<ksgeograf>	For 2.1, I can live with stable and slow... Right now anything is better than a constantly crashing service
	<jasonbirch>	OK, so as long as you're open to working on the connection manager for 2.1.1, then I'd be happy to see 2.1 ship with just the BFL :)
	<ksgeograf>	yes, I don't think that refcounting is the best possible way to determine usage of a connection
	<HarisK>	Kenneth, yes only adding ref to provider will halt MG ( or in combo with lock) can't remember now
	<bdechant>	I'm happy to work on the FDO connection manager post 2.1
	<jasonbirch>	I'd be worried about fixing the refcounting, if HarisK saw a negative interaction between that and the lock.
	<tomf2>	jasonbirch: BTW I got some news today that there may be a problem with the way the web tier closes connections and this may cause some instability. Perhaps this is one of the stability issues you are seeing?
	<jasonbirch>	tomf2: yes, quite possibly.
	<jasonbirch>	tomf2: is fix for that likely to make it into 2.1? :)
	<tomf2>	jasonbirch: ask Trevor :)
	<rbray>	So are we done?
	<tomf2>	I think that supporting many concurrent users hasn't been thoroughly done yet. And it seems that many developers are working on this at the same time
	<tomf2>	Would it be worthwhile to set up a wiki or something for people to put their findings?
	<rbray>	We should just make an area on the trac wiki for that
	<rbray>	and Yes - that would be helpful as long as people update it
	<jasonbirch>	I plan to blog about the use of 'The Grinder" to replicate many users too. All of my testing so far has been with real users, but artificial load can be useful too.
	<jasonbirch>	Haris used it to good effect for the raster testing.
	<tomf2>	We use the GRinder here for our load tests
	<tomf2>	Chris has made some nice scripts
	<jasonbirch>	Oh. Would be cool to share those in the SVN :)
	<HarisK>	great, share it please :)
	<ksgeograf>	Is this the final suggestion for 2.1 then?
	<ksgeograf>	* Suggestion:
	<ksgeograf>	* Add the two fixes produced by Haris
	<ksgeograf>	* Add the refcount fix produced by Traian, and initially suggested by Haris
	<ksgeograf>	* Add a lock produced by Haris, but not yet submitted as a patch
	<HarisK>	we obviusly need better unittest
	<jasonbirch>	ksgeograf: I think all we're going to add is the big lock in the stylization code.
	<rbray>	ksgeograf: I believe so
	<tomf2>	Chris is on holidays until the 20th
	<tomf2>	Remind me at that time
	<jasonbirch>	tomf2: will do.
	<ksgeograf>	the one called "mapguide_raster_stability.patch" ?
	<tomf2>	I'm done, thanks Bob
	<jasonbirch>	I think so. The other one was already submitted (in a modified form)
	<rbray>	OK, so that's what we'll do for 2.1
	<rbray>	I have to run, so thanks everyone
	<jasonbirch>	And adding the refcounting fixes into fdo 3.4 may introduce more instability.
	<jasonbirch>	Nice short meeting...
	<Traian_>	jasonbirch: the refcounting fix does not introduce instability, but is useless if there is a giant lock. Of course, I can't convince you of that by just saying it.
	<jasonbirch>	no :)
	<jasonbirch>	Show me the money :)
	<Traian_>	it's impossible to prove that a problem doesn't exist
	<Traian_>	it's a general scientific concept
	<jasonbirch>	exactly...
	<Traian_>	the burden is on you to show a problem...
	<ksgeograf>	:D
	<Traian_>	I would personally go to B.C. and buy you a a beer if the lock + refcount fix breaks rasters...
	<Traian_>	and then go to Slovenia to buy a beer for Haris
	<jasonbirch>	OK, so if first thread has strong connection to fdo provider, and does execute, then second thread comes in and there's only a single connection what happens? Does it throw exception because second connection can't be opened? Or does it wait for the first one to close then proceed?
	<Traian_>	it waits
	<bdechant>	there is retry logic to wait
	<HarisK>	and it gies out after a short period
	<Traian_>	right, the retry logic kicks in
	<HarisK>	and with many concurent users no images for them
	<ksgeograf>	so it waits, then retries?
	<HarisK>	it doesnt work
	<Traian_>	I tested it with many concurrent and it worked fine
	<Traian_>	many = 16
	<HarisK>	on very short raster access yes
	<HarisK>	ut it doesnt really work
	<Traian_>	I tested with short and long (small and big rasters). Of course, I can't be 100% sure it works.
	<Traian_>	You guys have more real tests
	<HarisK>	we will talk about beer :)
	<HarisK>	either in Canada or Slovenia
	<Traian_>	Haris: it will have to be in June/July, that's when I go visit in the area
	<jasonbirch>	Haris will be in BC for GeoWeb :)
	<jasonbirch>	I wonder who else here is going to be there...
	<ksgeograf>	So, If I were to produce a raster provider with the fixes submitted by Traian, on a MapGuide running with the patched dll's Jason made, it would lock up?
	<HarisK>	great
	<Traian_>	I can send you guys a patched provider to play with
	<Traian_>	I compile against trunk, so I need to rebuild on 3.4...
	<jasonbirch>	Traian_: can you rebuild against 3.4 but using GDAL 1.6? :)
	<Traian_>	I can, but I thought it was using GDAL 1.6 already...
	<jasonbirch>	Oh...
	<jasonbirch>	You're right. I was thinking 3.3
	<jasonbirch>	Kenneth's still running MG 2.0.2 I think.
	<Traian_>	urgh
	<ksgeograf>	yes I am :D
	<jasonbirch>	I am too, in production.
	<jasonbirch>	But am testing against 2.1
	<Traian_>	in Open Source time frames, that's like running a Ford Model T
	<Traian_>	:)
	<ksgeograf>	I have MGE 2010 running in test, but I can't get the OGR provider working
	<HarisK>	I forgot a bit, but trying to remember
	<HarisK>	only adding ref count to provider will again throw exception
	<Traian_>	what part of OGR doesn't work?
	<Traian_>	HarisK: it would help if you tell me what exception -- I have found another problem which has to do with threading, when parsing XML using FDO's XML stuff.
	<ksgeograf>	not sure yet, it just throws Unclassified Exception
	<ksgeograf>	and occasionally "Resource busy"
	<Traian_>	what driver? PostGIS?
	<ksgeograf>	MapInfo
	<Traian_>	hmm... MapInfo is file-based, should be rock solid... Strange.
	<ksgeograf>	Not really asking for help, just an excuse for driving a Ford T :D 
	<jasonbirch>	Is OGR provider advertised as single-threaded? :)
	<ksgeograf>	not sure...
	<Traian_>	No, MapGuide does dangerous things when the provider says "single-threaded" :)
	<jasonbirch>	Yeah, it's hard-coded to set the pool size to 1, regardless of the settings in the config file.
	<jasonbirch>	That was a bit annoying :)
	<tomf2>	was?
	<jasonbirch>	For Haris when trying to figure out why his config file settings weren't changing the behaviour :)
	<tomf2>	Ah, I see
	<Traian_>	Yeah, I had the same problem with the settings when I was testing... Took a while to figure out.
	<tomf2>	Traian_, what are those dangerous thrings?
	<Traian_>	It was a joke -- it's the override setting that sets the Gdal provider to use one connection
	<Traian_>	it's not necessary anyway, since the provider already reports it's single-threaded
	<Traian_>	when I removed the setting from the config, it still remained single connection limit and I couldn't figure out why...
tomf2>	Blame bdecahnt :)
	<Traian_>	so, was there a decision what to do for 2.1?
	<jasonbirch>	I think it was commit the lock and be done with it.
	<Traian_>	ok
	<ksgeograf>	do you mean: not fix the refcounting?
	<jasonbirch>	The lock works OK without it, and make it pointless.
	<Traian_>	The refcounting is not a problem if the global lock is there... Unless you are doing something other than stylization, in which case you are screwed.
	<Traian_>	Since other APIs don't have the global lock...
	<ksgeograf>	ok, so basically what is out now in the patched dll's ?
	<jasonbirch>	ksgeograf: yes.
	<jasonbirch>	The memory leak was already fixed by ADSK for 2.1
	<jasonbirch>	And the second issue has been committed by Walt,
	<jasonbirch>	So the lock is all that's remaining.
	<ksgeograf>	ok