*** mnemoc_ has joined #gnuenterprise
*** mnemoc_ has quit IRC
*** mnemoc has quit IRC
*** titopbs has quit IRC
*** mnemoc has joined #gnuenterprise
*** crazyzivi has joined #gnuenterprise
*** crazyzivi has left #gnuenterprise
*** reinhard has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** btami has joined #gnuenterprise
<btami> good morning
* btami is reading logs
<btami> tiredbones: http://www.gnuenterprise.org/tools/forms/docs/Developers-Guide.sxw is what you are looking for
<lekma> morning btami
<reinhard> good morning
<lekma> hi reinhard
<reinhard> lekma: you're already running threaded?
<lekma> i try to
<lekma> but only the xul engine
<lekma> atm
<lekma> i really would like to thread the xmlrpc server
<lekma> but i'm lost in gnue code
<lekma> there's only one thread at a time used by xmlrpc server
<btami> hi lekma, reinhard
<lekma> which slows down all sessions
*** dcmwai has quit IRC
<ajmitch> morning
<reinhard> lekma: making a program like gnue-appserver multithreaded is probably a big and complex task
<lekma> this i did consider already
<lekma> but there are small possible things
<lekma> to do
<reinhard> let me look again at your traceback
<lekma> i think
<lekma> at least
<lekma> reinhard: thx
<ajmitch> making it multithreaded would probably expose hidden bugs :)
<lekma> :)
<lekma> a few of them seem to be hidden (quite well) in DBSIG2
*** kilo has joined #gnuenterprise
<reinhard> lekma: are you aware of the fact that calling functions like find() or new() call stuff throughout appserver?
<reinhard> that means that if you call find() or new() in different threads, you in fact run appserver multithreaded
<lekma> yep
<lekma> this i know
<lekma> but my prob
<lekma> my main prob
<lekma> is that xmlrpc
<lekma> only answer one request at a time
<lekma> so even if xul engine seems to be threaded
<reinhard> yes I see
<reinhard> if one user sends a long request to the appserver
<reinhard> the rest of the users are blocked for that time
<lekma> you have to wait for every request to finish
<reinhard> correct?
<lekma> yep
<reinhard> well yes
<lekma> <reinhard> that means that if you call find() or new() in different threads, you in fact run appserver multithreaded
<lekma> that's what i do with xul engine
<reinhard> ok
<lekma> it a kind of appserver client
<lekma> that thread every possible requests
<kilo> good morning
<lekma> mornng kilo
<lekma> s/mornng/morning
* lekma is tired, again a sleepless night working on appserver
<lekma> :)
<kilo> hi lekma
<kilo> reinhard: what should I do to refresh Forms' DevGuide that is linked on the web? http://www.gnuenterprise.org/tools/forms/docs/Developers-Guide.sxw is older than the current one in SVN
<reinhard> upload?
<kilo> ?
<reinhard> kilo: you have an account on ash?
<kilo> aye
<reinhard> upload the current version to ash /var/www/tools/forms/docs/
<reinhard> lekma: the traceback you get is impossible...
<kilo> should i scp it there? ain't it linked somehow? strange...
<reinhard> kilo: I guess it ain't
<kilo> hmmm
<reinhard> lekma: self._dataObject gets initialized at object creation for ResultSet
<reinhard> so self._dataObject *can* never be None
<reinhard> this is absolutely weird
<reinhard> either we face a race condition here
<lekma> well here is another one...
<lekma> DB000: Exception in thread Thread-2660:
<lekma> DB000: Traceback (most recent call last):
<lekma> DB000:   File "/usr/lib/python2.3/threading.py", line 436, in __bootstrap
<lekma> DB000:     self.run()
<lekma> DB000:   File "/var/lib/gnue/gecocer/xul/forms.py", line 231, in run
<lekma> DB000:     self.obj = self.attr.getXulAttr (self.obj, self.item)
<lekma> DB000:   File "/var/lib/gnue/gecocer/xul/attributes.py", line 146, in getXulAttr
<lekma> DB000:     attribs = self.__session.find (klass, cond, [], props)
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/Session.py", line 119, in find
<lekma> DB000:     properties)
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/ObjectList.py", line 48, in __init__
<lekma> DB000:     self.__buildList ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/ObjectList.py", line 108, in __buildList
<lekma> DB000:     self.__populateList ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/language/ObjectList.py", line 118, in __populateList
<lekma> DB000:     rset = sm.fetch (sid, self.__list_id, len (self.__list), self.__cacheStep,0)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasSessionManager.py", line 300, in fetch
<lekma> DB000:     result = s.fetch (list_id, start, count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasSession.py", line 467, in fetch
<lekma> DB000:     result = list.fetch (start, count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 260, in fetch
<lekma> DB000:     self.__fillupFunc (start + count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 76, in __fillupFunc
<lekma> DB000:     return self.__fillupUnsorted (count)
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 133, in __fillupUnsorted
<lekma> DB000:     current = self.__getInstance ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/geasList.py", line 163, in __getInstance
<lekma> DB000:     record = self.__recordset.nextRecord ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/data.py", line 973, in nextRecord
<lekma> DB000:     rec = self.__nextBackendRecord ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/data.py", line 1087, in __nextBackendRecord
<lekma> DB000:     beRec = self.__resultSet.nextRecord ()
<lekma> DB000: AttributeError: 'NoneType' object has no attribute 'nex
<lekma> DB000:     rec = self.__nextBackendRecord ()
<lekma> DB000:   File "/usr/lib/gnue/appserver/data.py", line 1087, in __nextBackendRecord
<lekma> DB000:     beRec = self.__resultSet.nextRecord ()
<lekma> DB000: AttributeError: 'NoneType' object has no attribute 'nextRecord'
<lekma> pasted in two times
<lekma> too long
<reinhard> hrmmm
<reinhard> if I only knew more about multithreading
<lekma> :)
<reinhard> different threads run in the same address space, right?
<lekma> unfortunately
<reinhard> they share all memory
<lekma> i don't know more than you
<lekma> i think so
<lekma> they run in main thread memory space
<lekma> i think
<lekma> you know a few month ago you would have ask me what was the meaning of programming
<lekma> i would have answered uh??
<lekma> :)
<reinhard> lekma: you joking?
<lekma> nope
<lekma> i learned by doing
<lekma> which tells a lot about the quality of my code
<lekma> :)
<reinhard> *lol*
<lekma> brb, smoke break
<lekma> :)
<reinhard> I don't think there's a connection between that
<reinhard> I program since I was 12
<reinhard> and my code isn't that good, either :)
<ajmitch> better than mine ;)
<kilo> reinhard: you started with what kind of machine?
<reinhard> commodore vic 20
<reinhard> then commordore 64, atari 800xl, dec vax at school, then pc
<kilo> hehe, i started on RXX (dont remember exact number) via terminals, then ZX81, Spectrum, C64, then pc
<lekma> reinhard: there should be an easy way to thread xmlrpc server
<lekma> but i'm really lost in all those common.rpc files
<lekma> i tried to do it with SimpleXMLRPCServer.py
<lekma> and it works
<lekma> (only by replacing to occurences of SocketServer.TCPServer by SocketServer.ThreadingTCPServer)
<lekma> but with gnue common i feel in the middle of a labyrinth
<lekma> too much layer of abstraction
<lekma> gives me a headache
<lekma> :)
<lekma> after the fifth file open chasing server init i was wondering where i started already
<lekma> :)
<kilo> well known gnue feature... 8-))
<reinhard> lekma: now you see what I have to face every day
<reinhard> I have to *code* against common...
<lekma> lol
<ajmitch> heh
<ajmitch> reinhard: you love it ;)
<reinhard> seriously I don't
<ajmitch> rewrite common? :)
* reinhard would like to point out that most of the code in common was not done by him...
<kilo> rewrite common in C?
<ajmitch> appserver has already been tried in C
<kilo> then in assembly 8-))
<kilo> seriously i dont know if it could earn something by that...
<kilo> so it is only joke
<ajmitch> rewrite it in java & be done with it
<kilo> brrrrrrrr
<reinhard> lekma: I think one of the problem fields with multithreading is
<reinhard> say you request a list
<reinhard> and in another thread you fetch data from that list
<reinhard> the request() may not be through
<reinhard> but actually I think what I say makes no sense
<reinhard> because you can't fetch() without waiting the request() to return
<lekma> and count()
<lekma> i think
<reinhard> I think you will get problems as soon as you act on the same session from different threads
<reinhard> well honestly I think you will always have problems as soon as you use threads at all :(
<reinhard> has anybody here at all ever written a truely multithreaded program?
<lekma> well at least we could have one thread per session
<lekma> instead of one for all of them
<lekma> atm i only use threads for session.find()
<lekma> and they never try to get the same data
<lekma> even though they access the same classes
<reinhard> and these find()s run on the same session or on different sessions?
<lekma> same session
<lekma> well it's always one session at a time atm
<lekma> so they can't get in the way of each other
<lekma> in fact that's what i'm trying to find out
<lekma> how i can get them to step on each other toes
<lekma> :)
<lekma> maybe i'll get a nice firework
<kilo> <reinhard> has anybody here at all ever written a truely multithreaded program?
<kilo> i did, in 1995, in C
<kilo> but it was only about 100 lines...
<reinhard> lekma: currently, it looks very much to me as if two different threads would fetch from the same list
<reinhard> first of all, you could check if really all lists get an unique list id
<reinhard> :q
<reinhard> err
<reinhard> wrong window
<lekma> which debug level should i use??
<lekma> 456
<lekma> or 4,5,6
<lekma> or 4-6
<reinhard> you get the list id as result of request()
<reinhard> in your own code
<lekma> i use find() only atm for threads
<lekma> it doesn't return list id
<lekma> is it??
<reinhard> ah no
<lekma> for one request from xmlrpc client
<lekma> there dozens of find
<lekma> so list id jumps from 873 to 956
<lekma> all missing are find
<lekma> i think
<reinhard> lekma: in language/ObjectList.py you can see where the find in fact alls a request()
<reinhard> and the list id is fed into self.__list_id
<reinhard> you can add a print self.__list_id there for example
<lekma> reinhard: well they seem to have unique id
<reinhard> that's good
<lekma> the error occur between 450 and 451
<reinhard> you can reproduce the error?
<reinhard> same error every time?
<lekma> yep
<lekma> it's not happening always
<lekma> but when it happens it's always at the same request
<lekma> what are the new debug-level to see just sql request??
<reinhard> 3
<lekma> list ids should be unique throughout one session, correct?
<reinhard> yes
*** sjc has quit IRC
<reinhard> lekma: next random guess: do you close sessions or lists manually in your application?
<lekma> yep
<reinhard> exactly your effect should be reproducible by closing a session while another thread still runs a find() in that session
<lekma> i don't close session but lists
<reinhard> ok
<reinhard> the same holds for closing lists while there's still some processing running in that list
<lekma> +  def closeLists (self):
<lekma> +
<lekma> +    for item in self.__lists.values ():
<lekma> +      item.close ()
<lekma> in geasSession
<lekma> oh
<reinhard> that looks very dangerous
<reinhard> closing the list frees quite some objects in memory
<lekma> that's the point
<reinhard> that are needed in find() and such
<lekma> otherwise there's memory use inflation
<lekma> :)
<lekma> i'll try without the closeList
<lekma> but it seems odd to me
<lekma> cause i wait for all threads to finish
<lekma> before returning anything
<lekma> and then when there is result
<lekma> i closeLists
<reinhard> well, what I can say quite surely is that geasList.close() runs too early
<lekma> ok
<lekma> i'll test it
<lekma> thx for helping
<reinhard> either that or the last part of __getInstance
<reinhard> those are the only 2 points where geasList.__recordset is set to None
<reinhard> and one of your exceptions IIRC clearly stated that geasList.__recordset is None
<lekma>  the last part of __getInstance <-- ??
<lekma> in geasList??
<reinhard> yes
<reinhard> that part where self.__recordset is set to None
<reinhard> actually that part should only run when all record have been fetched anyway
<reinhard> and you are at the end of the list
<reinhard> so I much more suspect close() than that
<lekma> nope without closeLists triggered, i still have the same error
<reinhard> lekma: you could add a test print at both points to find out which of them actually gets executed
<reinhard> maybe with printing the list id
<reinhard> bad thing is I'm not sure whether multithreaded programs show their output in the true order
<lekma> not really
<lekma> reinhard: do you have any idea what the following could mean in less rich words
<lekma>    File "/usr/lib/gnue/appserver/language/Session.py", line 119, in find
<lekma>     properties)
<lekma>    File "/usr/lib/gnue/appserver/language/ObjectList.py", line 48, in __init__
<lekma>     self.__buildList ()
<lekma>    File "/usr/lib/gnue/appserver/language/ObjectList.py", line 106, in __buildList
<lekma>     self.sortOrder, self.properties)
<lekma>    File "/usr/lib/gnue/appserver/geasSessionManager.py", line 272, in request
<lekma>     result = s.request (classname, conditions, sortorder, propertylist)
<lekma>    File "/usr/lib/gnue/appserver/geasSession.py", line 391, in request
<lekma>     recordset = self.__connection.query (content, dsCond, sortlist)
<lekma>    File "/usr/lib/gnue/appserver/data.py", line 645, in query
<lekma>     content, _conditionTree (conditions), order)
<lekma>    File "/usr/lib/gnue/appserver/data.py", line 939, in __init__
<lekma>     self.__mergeWithCache (conditions, order)
<lekma>    File "/usr/lib/gnue/appserver/data.py", line 1153, in __mergeWithCache
<lekma>     self.__removeFilter (row, conditions)
<lekma>    File "/usr/lib/gnue/appserver/data.py", line 1205, in __removeFilter
<lekma>     if not condition.evaluate (lookup):
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 120, in evaluate
<lekma>     if not child.evaluate (lookup):
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 120, in evaluate
<lekma>     if not child.evaluate (lookup):
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 577, in evaluate
<lekma>     GBinaryConditionElement.evaluate (self, lookup)
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 380, in evaluate
<lekma>     self.values = unify ([child.evaluate (lookup) for child in self._children])
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 1147, in unify
<lekma>     __unify (values, result)
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 1245, in __unify
<lekma>     raise ConversionRuleError, (oldValue, chkValue)
<lekma>  ConversionRuleError: No unification rule for combination 'int' and 'bool'
<reinhard> that means that you try to compare an integer with a boolean
<reinhard> in a condition
<lekma> in a find() condition??
<mnemoc> http://uml2svg.sourceforge.net/ <--- gsd2xmi?
<reinhard> lekma: yes, in a find() condition
<kilo> mnemoc: hmmm, maybe
<lekma> i don't get it, i don't compare oranges and apples
<lekma> and still i get this mysterious error
<reinhard> what *do* you compare?
<lekma> strings with strings, bool with bool, ...
<reinhard> can you find out exactly which condition causes this error?
<lekma> yep i'll try right now
<kilo> bbl
*** kilo has quit IRC
<lekma> SELECT t1.docs_docId,t2.gnue_id,t1.gnue_id,t0.gnue_id FROM docs_Series t0 LEFT JOIN docs_Docs t1 ON t1.gnue_id = t0.docs_docId LEFT JOIN docs_Docs t2 ON t2.gnue_id = t0.docs_serieId WHERE (((t2.docs_docId = '600003')))
<lekma> that's the last select before error
<lekma> there are not even bool or int
<lekma> and in db it works
<reinhard> brb phone
<tiredbones> I was using gnue-designer and took a segfault. I was doing my third unbound entry. Error :TODO UPDATING VALID SET
<reinhard> lekma: you should be able to find out which find() this is
<reinhard> the error happens in an appserver-evaluated part of the condition
<reinhard> let me explain
<reinhard> when you give a condition to find, it gets split into a part that the db must handle, and another part that appserver must handle (e.g. because it contains calculated fields)
<reinhard> what you see in the select is the db part of the condition
<reinhard> appserver goes through every record of the result set and checks if it's part of the condition is ok or not
<reinhard> and discards the records where the "appserver-part" of the condition is false
<lekma> well i found out which part of condition was a pb
<lekma> but it's still odd
<lekma> i was comparing a boolean to True
<lekma> it's a boolean in db
<lekma> it's a boolean in gcd
<reinhard> odd
<lekma> it's a boolean in gnue_property
*** btami has quit IRC
<lekma> i can't compare anymore to True or False in bound proc
<lekma> i always got this error
<lekma> that sucks
<lekma> i'm tired
<lekma> :(
<reinhard> let me check something
<reinhard> lekma: I think I found it
<reinhard> lekma: can you please svn up common/rcp and try again?
<lekma> ok
<reinhard> and if it doesn't work, try rpc instead of rcp ;-)
<lekma> how can i selectively svn only a folder
<lekma> ??
<reinhard> go to that folder and "svn up" there
<lekma> nope doesn't work
<reinhard> hrmm... must try to reproduce
<reinhard> just to make sure: "svn up" doesn't work or condition doesn't work?
<lekma> session.find () in onvalidate with a cond like {'class_prop': True}
<lekma> where module_class is bool
<lekma> condition doesn't work
<reinhard> ok
<lekma> is there a debug-level available to see all the non xmlrpc stuff appserver does??
<lekma> brb
<lekma> reinhard: can you reproduce or am slowly beginning to go down the path of insanity??
<lekma> :)
*** SachaS has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
<reinhard> lekma: I can not reproduce
<reinhard> sorry for my bad response time (even worse than appserver) - I'm doing 3 or 4 things at the same time
<lekma> ok, that's official, i am insane
<lekma> :)
<reinhard> no
<reinhard> a few question
<reinhard> the boolean field you check is a db field or a calculated field?
<lekma> db
<reinhard> does the class contain dirty instances at the time you read it?
<reinhard> or is any calculated field involved in the same condition?
<lekma> no calculated field, but at the time of validation self is in dirty instance
<lekma> which on second read seems obvious
<reinhard> lekma: are you sure this worked before?
<reinhard> and if yes can you say when it last worked?
<lekma> yes i am
<lekma> i didn't need it for a long time (at least few weeks)
<reinhard> ok
<reinhard> so it could be that it broke with dirty reads?
<lekma> so i don't remember when it last worked
<lekma> maybe
<lekma>             myArt = session.find ('articles_Articles', {'articles_docId.docs_docId': serie.docs_docId.docs_docId, \
<lekma>                                                         'articles_version.articles_varKeyId': self.articles_version.articles_varKeyId, \
<lekma>                                                         'articles_support.articles_varKeyId': self.articles_support.articles_varKeyId, \
<lekma>                                                         'articles_standard.articles_varKeyId': self.articles_standard.articles_varKeyId}, [], [])
<lekma> this works
<reinhard> I think I found a solution
<reinhard> just a second
<lekma> but if i add 'articles_valid': True
<lekma> it borks
<reinhard> can you please svn up in gnue-common/src/datasources and try again?
<lekma> ok
<lekma>    __unify (values, result)
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 1273, in __unify
<lekma>     __unify (values, result)
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 1158, in __unify
<lekma>     checktype (values, types.ListType)
<lekma>  RuntimeError: maximum recursion depth exceeded
<lekma> i just pasted the last lines
<reinhard> weee
*** jcater has joined #gnuenterprise
<lekma> :)
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** ChanServ sets mode: +o jcater
*** jcater_ was kicked by jcater (jcater)
*** jcater sets mode: -o jcater
*** dcmwai has joined #gnuenterprise
<reinhard> lekma: next try
<reinhard> can you again svn up in datasources?
<lekma> gnue-common/src/datasources??
<reinhard> (sorry for this tral and error but I can't easily reproduce)
<reinhard> yes
<lekma> np, i'm so glad you help
<lekma> no luck
<lekma> doesn't work
<lekma> i think i will let it sink for today
<lekma> and check it back tomorrow
<reinhard> what symptom?
<lekma>    File "/usr/lib/gnue/common/datasources/GConditions.py", line 1264, in __unify
<lekma>     raise ConversionRuleError, (oldValue, chkValue)
<lekma>  ConversionRuleError: No unification rule for combination 'bool' and 'int'
<lekma> i really don't get it
<lekma> maybe i'm too tired
<lekma> i don't see the obviou
<lekma> s
<reinhard> sorry
<reinhard> spotted a typo
<reinhard> lekma: you have power for another try?
<lekma> ok
<reinhard> fix committed
<reinhard> ..
<reinhard> ....
<reinhard> now
<lekma> reinhard: you're a damn genius!!!
<lekma> it works again
<reinhard> lekma: no
<reinhard> lekma: i'm a damn fool - would have worked the first time already if i'd fixed it corectly
<reinhard> :)
<lekma> :)
<SachaS> :)
<SachaS> lekma: if I would not have seen in real I would think reinhard and johannes are some form of artificial intelligence machines
<SachaS> ;)
<SachaS> virtual ones
<reinhard> what still strikes me odd at some times is that I can look at johannes' code I've never looked at before and withing a few minutes understand it enough to fix something
<lekma> you both make a hell of a team
<SachaS> reinhard: i found your quote from Tannenbaum: "The nice thing about standards is that you have so many to choose from. Furthermore, if you do not like any of them, you can just wait for next years's model."
<reinhard> SachaS: lol - never heard the second sentence
<reinhard> well, actually gnue's line is more like "standards are so cool - everybdoy should have his own"
<reinhard> ;-)
<SachaS> :)
*** wendall911 has joined #gnuenterprise
<reinhard> off for toda
<reinhard> today
<reinhard> cu all
*** reinhard has quit IRC
<lekma> so who's the one i talk to about the gnue xmlrpc server??
<lekma> :)
<lekma> SachaS: are you working on pyro??
<SachaS> i am not working on anything for gnue :(
<SachaS> i just hang out here ;)
<lekma> :)
*** jamest has joined #gnuenterprise
*** nickr_ has joined #gnuenterprise
*** nickr has quit IRC
*** holycow has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** dcmwai has quit IRC
*** dimas has quit IRC
*** jamest has left #gnuenterprise
*** cilkay has quit IRC
*** SachaS has quit IRC
*** titopbs_ has joined #gnuenterprise
*** titopbs has quit IRC
*** siesel has joined #gnuenterprise
<siesel> hi
<siesel> lekma, you've interest in rpc?
<lekma> i have questions and pbs
<lekma> :)
<lekma> i wonder if the xmlrpc server is a threaded one
<lekma> cause we're implementing appserver
<lekma> right now
<siesel> at least one of the two appserver versions is threaded.
<siesel> oops, I mean xmlrpc server versions
<lekma> but right now with 10 people working together we never more than one thread
<lekma> used by the server
<lekma> and we all have to wait for the previous call to finish
<siesel> ok, got it.
<lekma> that's pretty annoying
<lekma> reading the code (for what i can read) the server is threaded
<lekma> but that's not what it looks like in prod
<lekma> there's never more than one server thread running
<lekma> could it be that our rpc call are sync calls??
<siesel> The client side does sync calls, but the server should do it.
<siesel> Seems like I have to test it.
<lekma> i'd be glad if you can help on this one
<siesel> np
<wendall911> hey guys a OT question
<wendall911> undergoing a mail bomb and wondering if there is a quick way I can disable a domain in postfix, so it drops all mail from it instantly.
<lekma> not a postfix user here
* wendall911 hasn't had to do this task before
<lekma> siesel: i'm using xmlrplib from python std
<lekma> if this can help
<lekma> :)
<siesel> ok. I thought so.
<siesel> Do you know how to make python wait?
<lekma> time.sleep
<siesel> cool
<lekma> import time
<lekma> brb
*** titopbs_ has quit IRC
*** titopbs has joined #gnuenterprise
<siesel> lekma, it works, the xmlrpc server is threaded
<lekma> wow
<lekma> can i svn up
<lekma> ?
*** kilo has joined #gnuenterprise
<siesel> sorry,i didn't use appserver, but an test programm
<lekma> i'm eager to test it
<lekma> :)
<lekma> brb
*** jcater has quit IRC
<siesel> lekma: I've tried it with appserver, and it seems to work too.
<lekma> great
<lekma> :)
<siesel> I've used the following trick
<siesel> add a line "time.sleep" to one of appserver functions (in geasSession.py)
<lekma> ??
<lekma> how much time.sleep??
<lekma> :)
<siesel> then call "testRPC.py"  on two different terminals. Then you can see, that the call (with time.sleep) from the first one will be interupted by the second one
<siesel> 6
<lekma> oh you mean without modification the xmlrpc server is threaded
<siesel> yep
<lekma> i was at lost here
<lekma> i thought you made some modif
<lekma> hmmm
<siesel> no, not needed
<lekma> so what we see is kinda odd then
<lekma> cause we send a lot of client rpc sync calls
<lekma> and the server never runs more than one thread to answer all these calls
<lekma> do you have a hint
<lekma> ?
<siesel> how do you know thats allways just one thread?
<lekma> watching top
<lekma> there's the 3 main threads
<lekma> always running
<lekma> but for each call
<lekma> there's one thread showing up
<lekma> then finishing
<lekma> then next one
<lekma> never more than one at a time
<lekma> i'm running a threaded client to appaserver
<lekma> and when it lauches 10 or more threads you can feel the difference
<lekma> feel and see actually
<siesel> how do you see the number of threads in top? I never cared for
*** holycow has quit IRC
*** titopbs has quit IRC
<siesel> n8t
*** siesel has quit IRC
*** lekma has quit IRC
*** wendall911 has left #gnuenterprise
*** ajmitch has quit IRC
*** jamest has joined #gnuenterprise
*** kilo has quit IRC
*** sjc has quit IRC
*** dcmwai has joined #gnuenterprise
*** ajmitch has joined #gnuenterprise
*** dcmwai has quit IRC
*** titopbs has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** titopbs has quit IRC
*** dcmwai has quit IRC
*** jcater has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** jcater has quit IRC
*** dcmwai has joined #gnuenterprise
*** tiredbones has quit IRC