You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Sahan Gamage <sa...@gmail.com> on 2006/06/14 12:40:41 UTC
Chat log (06/14/2006)
samisa> hello
<paulfremantle> hi
<paulfremantle> we are a bit early
<chamikara> hi all
<chamikara> ya abt 10 mins
<paulfremantle> while we are waiting
<paulfremantle> has anyone set up Microsoft VC express (the free one)
to build axis-c?
<paulfremantle> axis2-c
<paulfremantle> i should say
<samisa> we do not have projects
<samisa> we have the build files
<samisa> nmake files that is
<paulfremantle> it would be really helpful to us Windows users if
someone who has got it working could make notes on how
<paulfremantle> I tried once a while ago
<paulfremantle> but didn't succeed
<paulfremantle> I'd love to have it building
<samisa> hmm
<paulfremantle> If no-ones done it then I can try again
<sahan> we cannot create project with the free version of MSVC
<paulfremantle> ahhh
<samisa> you can build with nmake
<paulfremantle> ok
<paulfremantle> cool
<samisa> we have to document it I guess
<sahan> So basically we need help from someone who have a licenced
version of MSVC
<paulfremantle> that would be great
<paulfremantle> i guess WSO2 could fork out for that
<paulfremantle> :-)
<chamikara> :-)
<paulfremantle> at least one copy so we can make the proj files
<sahan> IIRC Ed Slaterry started a JIRA to put up MSVC projects
<paulfremantle> ok
<chamikara> shall we start now
<paulfremantle> sure
<sahan> ok
<paulfremantle> I guess Jaliya is still asleep :-)
<sahan> :)
<chamikara> jaliya tried to connect. but seems like hes having some
proxy issues
<paulfremantle> oh no
<paulfremantle> at 530 in the morning thats no fun
<chamikara> ya
<paulfremantle> so I guess this is my fault
<paulfremantle> :-)
<chamikara> :))
<paulfremantle> the main reason I wanted to do this
<paulfremantle> is that I would REALLY like Sandesha C to be fast
<paulfremantle> i mean really really fast
<sahan> :)
<chamikara> im sure it will be :-)
<paulfremantle> of course we also need to do some tuning on Axis Java :-)
<paulfremantle> Sandesha Java I mean
<paulfremantle> so a couple of things occurred to me
<paulfremantle> 1) i think it would be most efficient if we develop
well-defined structures
<paulfremantle> for all the data items related to each message and sequence
<paulfremantle> we could also think about using a state machine model
<paulfremantle> now that the RX TC has published some state tables :-)
<sahan> I see. What about the things we have in the Sandesha2/Java
<paulfremantle> do you mean the property bags?
<sahan> yes
<paulfremantle> well
<paulfremantle> I prefer structures :-)
<paulfremantle> but its my own preference
<paulfremantle> also
<sahan> Ultimately everyting will be structs in C :)
<paulfremantle> because we now have such good code
<paulfremantle> that passes the interop tests
<paulfremantle> (thanks Chamikara :-) )
<chamikara> :))
<paulfremantle> we know exactly what fields are needed
<paulfremantle> property bags are only going to add a few ms
<paulfremantle> there are other things to worry about too
<paulfremantle> so one main thing
<paulfremantle> is delivering messages
<paulfremantle> i have checked recently
<paulfremantle> Sandesha2 was ALWAYS doing a thread switch
<paulfremantle> even if the message could be delivered immediately
<sahan> that comes from the architecture itself I suppose (I mean the
sender thread and the invoker thread)
<paulfremantle> yes
<paulfremantle> but we ought to do a check
<samisa> can we do away with those?
<paulfremantle> noooo
<paulfremantle> well
<paulfremantle> sometimes
<paulfremantle> the invoker thread should only be used if:
<paulfremantle> 1) the "inorder" model is being used
<paulfremantle> and
<paulfremantle> 2) there are missing messages
<chamikara> agreed
<chamikara> but currently its not a performance hit
<samisa> ok
<paulfremantle> yeah but when we make the C code really fast it might
become one!
<chamikara> since we always pause the messages, before delivering to
the inVoker thread
<paulfremantle> but that is a perf hit
<samisa> performance is one concern. But there may be issues with the
non threading environments
<samisa> e.g. when we try to integrate with PHP
<paulfremantle> its going to be hard to do it without threading at some point!
<chamikara> hmm
<sahan> But we can always get the support of the underlying os (even
in PHP case)
<paulfremantle> chamikara....
<paulfremantle> do you know where there are other performance hits in Java?
<sahan> Agreed Paul .. the code will be very complicated if we try to
get rid of thereds
<paulfremantle> in other words, what else do we need to look at
<chamikara> abt the thread case
<paulfremantle> on the RMD side
<paulfremantle> you could manage without threads
<chamikara> ya
<chamikara> if in-order invocation is not required
<paulfremantle> or
<chamikara> that can be done
<chamikara> or if the msgs come in order always
<paulfremantle> if you do the delivery of a waiting message on the
thread of the missing message
<samisa> ok
<paulfremantle> so you have message 1 waiting
<paulfremantle> no
<paulfremantle> message 2 waiting!
<paulfremantle> and message 1 arrives
<paulfremantle> and on that thread you need to deliver message 1 and 2
<paulfremantle> no that probably doesnt work
<paulfremantle> not sure
<paulfremantle> anyway.... you certainly need threads to do it properly
<samisa> we can go for the threaded model for now and see what
happens when the PHP extention is going to use that
<chamikara> actually in the current implementation
<paulfremantle> yes
<chamikara> (as i can remember)
<chamikara> if in-order invocation policy is not set
<chamikara> the invoker thread will not be used
<chamikara> msgs will be directly invoked
<sahan> Even if we can .. I think we should not complicate the
architecture/code considering special cases
<paulfremantle> cool chamikara
<paulfremantle> nice one
<samisa> ok
<chamikara> so is that model ok for C as well ?
<samisa> ok fine
<sahan> It seems okay ...
<samisa> but we have to keep in mind that
<paulfremantle> well it would be good to make the extra optimization
<samisa> at some point extentions that use Axis2/C would have
implications related to thread
<paulfremantle> even if the inorder policy is on
<chamikara> thats a prob.
<paulfremantle> the thread shouldnt be used unless there are messages missing
<chamikara> until sandesha2 sees the first missing msg ?
<paulfremantle> yes
<samisa> ok I understand
<samisa> so lets worry about that later then
<sahan> That's a good point
<samisa> and lets move on
<paulfremantle> ok
<paulfremantle> +1
<chamikara> k
<samisa> ok
<paulfremantle> so chamikara
<paulfremantle> any other performance issues we can improve on?
<chamikara> well,
<chamikara> threading is the main issue i saw
<chamikara> thing the same storage model should be used for C as well
<chamikara> think
<chamikara> paul
<chamikara> abt the poing u hd mentioned in the mail
<chamikara> point
<paulfremantle> is it necessary to have the same storage?
<chamikara> do u think a change should be done to the property bag model
<sahan> well .. we don't have beans in C.
<paulfremantle> also no hibernate too
<chamikara> ya we should use the same storage
<chamikara> coz
<sahan> But I think some simple structs would do
<chamikara> we may need C to dump the data to the storage and Java to
pick them and invoke
<paulfremantle> ?
<chamikara> a hybrid model
<paulfremantle> explain that more please
<chamikara> sanjiva was talking abt such a model sometime back
<chamikara> where C side is used to manage sending and receiving
part, since its much faster
<paulfremantle> oh i see
<chamikara> but the actual invocation could be a java service
<sahan> I think we should try to achive some compromisation in the
fexibility in Java/Bean model and the performance in C struct model
<paulfremantle> wouldnt we have to do it the other way?
<paulfremantle> make Java understand the C storage?
<chamikara> well, we may
<paulfremantle> seems much harder to do the other way
<chamikara> so the best thing is to hv the same storage model
<paulfremantle> do we serialise any Java objects into the DB?
<chamikara> nop
<chamikara> only strings
<paulfremantle> k
<sahan> then the task would not be that hard
<chamikara> Java serialization is not used
<paulfremantle> good
<sahan> we can agree to a common database stucture
<paulfremantle> because the Java code is pluggable
<sahan> I don't know what hibernate does internally
<paulfremantle> not much
<chamikara> actually hibernate is not a issue
<paulfremantle> hibernate simply has some specific things you need to do
<paulfremantle> like having a long index on each table
<chamikara> ya
<paulfremantle> the only thing is
<paulfremantle> that the hybrid model is kind of a long shot
<paulfremantle> in other words its not that likely a scenario
<paulfremantle> because in real life its very complex
<paulfremantle> 1) you need a proper shared database (not Derby!)
<sahan> but if we use C we have to direcly talk with DB. So if
hibernate does some additional things (such as maintaining some
internal tables which are not visible to user) then we are in problem
<paulfremantle> no sahan hibernate is ok
<samisa> If we have a define table structures
<samisa> then DB can be either mySQL or postgres
<paulfremantle> all im saying is that I think we should let the C
model evolve and then sync up the database structures later
<samisa> ic
<paulfremantle> because we may make improvements in the C code and
then port those over to Java as well
<chamikara> agreed
<paulfremantle> so I'm hoping for 1000tps reliable on my thinkpad :-)
<sahan> :D
<samisa> :)
<paulfremantle> well i've talked to a few people
<paulfremantle> mainly in finance (wall street)
<paulfremantle> who like to put XML and SOAP and RM down
<paulfremantle> saying it can't perform
<chamikara> :-(
<paulfremantle> and i want to prove them WRONG :-)
<sahan> well ... the defn of *perform* depends on the load
<paulfremantle> sure
<sahan> If we see 10000 transactions we may not be able to with current models
<paulfremantle> but 1000 should be poss
<paulfremantle> of course i dont know what axis2c can do without RM
<sahan> we have to do a lot for that
<paulfremantle> i dont think so.... I did a little test
<paulfremantle> on an early axis2c driver
<sahan> Hmm ... we need perf numbers on axis2c
<samisa> yes
<paulfremantle> and i was doing 300tps with 30% cpu on my thinkpad
<samisa> we do not have numbers as yet
<paulfremantle> and that was with a sample that printed a line to
stdout for every invocation
<samisa> hmm cool
<paulfremantle> which isnt fast
<samisa> yes
<paulfremantle> i think we should aim that adding RM has a very small
impact as long as no messages are lost
<sahan> But given that we did not do a performance tweaking that's a
good number I think
<sahan> Processing wise we *should*
<paulfremantle> yes its a very good number!
<sahan> but what about the control msgs added by RM ?
<paulfremantle> well they can be minimum
<paulfremantle> for example you can send the CS/CSR
<paulfremantle> then you can add acks once every x ms (so not every message)
<sahan> I c
<paulfremantle> and send a nack when a message is missing
<chamikara> and piggybacking acks whenever possible
<paulfremantle> yes
<paulfremantle> but not every message needs an ack directly
<paulfremantle> its a balance
<paulfremantle> between cleaning out the store on the client side
<paulfremantle> and not adding too much extra bandwidth
<chamikara> So any other issues we should look into, in the early
stages of the C impl ?
<paulfremantle> no i think thats it for me
<chamikara> so we'll create the SVN locations as sahan as suggested
<paulfremantle> yes +1
<chamikara> and get it going :-)
<paulfremantle> cool
<sahan> ok cool
<chamikara> May be we should have regular chat sessions (may be every
two weeks) and discuss the issues
<chamikara> (on both C and Java)
<samisa> +1
<chamikara> ok guys
<chamikara> hv to leave the office :-)
<sahan> shall we wind up then ..
<chamikara> k
<paulfremantle> ok bye
<paulfremantle> will someone post this chat to -dev?
<chamikara> k, i will
<paulfremantle> cool
<sahan> ok bye
<chamikara> bye
<samisa> bye
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Chat log (06/14/2006)
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt, All,
+1.
Actually I guess it will be easier to do this on demand. I.e. we can do the
general discussions on the mailing list and go for a chat when necessary.
The time we can decide. I feel something like UTC 16 will be easier to
everybody (UK, SL, US).
Chamikara
On 6/15/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just following up to the chat you had the other day...
>
> <chamikara> May be we should have regular chat sessions (may
> be every two weeks) and discuss the issues
> <chamikara> (on both C and Java)
>
> That sounds like a great idea to me. Can we try and make sure it is an ok
> time zone for people in the UK, or adopt a rolling schedule like the main
> Axis2 chat?
>
> Thanks
>
> Matt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: Chat log (06/14/2006)
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt, All,
+1.
Actually I guess it will be easier to do this on demand. I.e. we can do the
general discussions on the mailing list and go for a chat when necessary.
The time we can decide. I feel something like UTC 16 will be easier to
everybody (UK, SL, US).
Chamikara
On 6/15/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just following up to the chat you had the other day...
>
> <chamikara> May be we should have regular chat sessions (may
> be every two weeks) and discuss the issues
> <chamikara> (on both C and Java)
>
> That sounds like a great idea to me. Can we try and make sure it is an ok
> time zone for people in the UK, or adopt a rolling schedule like the main
> Axis2 chat?
>
> Thanks
>
> Matt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: Chat log (06/14/2006)
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just following up to the chat you had the other day...
<chamikara> May be we should have regular chat sessions (may
be every two weeks) and discuss the issues
<chamikara> (on both C and Java)
That sounds like a great idea to me. Can we try and make sure it is an ok
time zone for people in the UK, or adopt a rolling schedule like the main
Axis2 chat?
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Chat log (06/14/2006)
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just following up to the chat you had the other day...
<chamikara> May be we should have regular chat sessions (may
be every two weeks) and discuss the issues
<chamikara> (on both C and Java)
That sounds like a great idea to me. Can we try and make sure it is an ok
time zone for people in the UK, or adopt a rolling schedule like the main
Axis2 chat?
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org