Re: Multi-threading
Hello, -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. The current implementation of a thread pool in axis is no thread pool but a collection of thread creation and deletion methods... So no... But when creating environment you can pass your own thread pool. Would that not help? No. The current implementation of axis relies on an infinite number of available threads. It assumes that when it requests a thread, it's getting one and it then starts the thread with a thread method / data. But in reality, a thread pool would have a finite number of (re-used) threads. In the case of axis, this would mean that the thread requesting the new thread would block until a new thread is available. This is not what you want. For axis to work with a finite number of threads, the way it uses threads should change. It should not request a thread, but it should submit a job (probably the thread method and data) to the thread pool. The submitting thread can then continue an the thread pool can decide when the job is performed by which thread. Regards, Quintiq Conference Quintessence 09 Tuesday May 12th, 2009, Country Estate Duin Kruidberg, near Amsterdam Schiphol, The Netherlands - for more information visit www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
Re: Multi-threading
Hi Patrick Patrick van Beem wrote: No. The current implementation of axis relies on an infinite number of available threads. It assumes that when it requests a thread, it's getting one and it then starts the thread with a thread method / data. But in reality, a thread pool would have a finite number of (re-used) threads. In the case of axis, this would mean that the thread requesting the new thread would block until a new thread is available. This is not what you want. For axis to work with a finite number of threads, the way it uses threads should change. It should not request a thread, but it should submit a job (probably the thread method and data) to the thread pool. The submitting thread can then continue an the thread pool can decide when the job is performed by which thread. Thanks for the explanation. I agree with it. thanks, Damitha -- __ Damitha Kumarage http://people.apache.org/ __
Re: RE : RE : Multi-threading
Patrick van Beem wrote: Hello Carl, It sounds like you would like to free resources on a per-call basis. Is that right? I'm quite new to the Axis2/C architecture so perhaps a more experienced person could suggest a mechanism that would fit into the existing methodology and provide this extra feature. My impression is that the design philosophy so far is to free resources after all calls are completed. I'm only in it myself for about a month too. But you're right on the design philosophy. Only: that's not the usage pattern of our application. We've got a (very) large client - server application where the user can write his own code (using a custom declarative / constraint programming language). Some interfaces available in this server programming environment perform calls to the outside world using soap. It's up to the user when and how to use it. So our framework must be flexible. We do not know in advance what the end-user is going to write. I was hoping to be able to re-use axis structures for each (parallel) call. Or cloning them. But indeed, this is not the design philosophy of axis. I'm now on the road of using thread local storage (TLS) to store the thread-specific structures, so I don't have to allocate / free them for each thread (my threads are worker threads that can do anything. Not just soap calls. So I can't (don't want) to design them for a set of specific soap calls). With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports... But I think they don't fit well in the modular (transportation) design of axis That's very interesting. I'm curious as to more of the details of how this functions... If you have one thread waiting on 12 sockets and want to make a new call, can this thread begin the next call, or does a second thread open the socket and pass the job of waiting on it to the first thread? The 'problem' is that the waiting thread can only wait on sockets. Not also on, for example, a job queue. So the waiting thread is mostly implemented as some round-robin algorithm: Wait on the sockets with a time-out of a few milliseconds, check a job queue and optionally perform a few tasks (open more sockets, accept a socket another thread opened, ...) and start waiting again on the new set of sockets. So this uses slightly more CPU then strictly necessary. The IO completion ports use a call-back strategy when IO on a socket is completed. This is a much nicer concept. If you're programming C++, you might be interested in the asio classes of the boost project, where the used IO completion for their windows implementation of the asio (asynchronous IO). But we're running out of context :-) I think we would all agree that your use case would benefit from adding this capability to Axis2/C. You mention a potential conflict with the modular design of Axis; there is also the idea that making such a powerful feature accessible to the average programmer using Axis could be a challenge. Maybe the solution would be to add a new communication mode instead of changing all asynchronous communication to one-thread-multi-socket. I wish I understood the Axis2/C architecture more fully because this would be an interesting area to contribute. I'm not 'deep' into the details of axis too (the idea was to use an existing toolkit to save on development time for soap, so I'm not planning to go into much detail for now either). But one implementation might be to add another 'configuration structure' (like the allocator and thread pool) for socket IO and make that responsible for all IO. That implementation can then decide to use one or multiple threads for IO. It can use call-backs to signal the completion (or failure or timeout) of the IO. The async calls can then be implemented as writing data (by the new io struct) and exiting that start-call. Finished. Nothing more to do. No extra thread, nothing. Then, when finished, the call-back can be used to parse the result and call the user call-back for the result. The io struct (module) should probably use a (real!) thread pool for this to prevent one time-consuming call to block other calls. But a simple implementation might to for the 'average' user. This pattern mimics the io completion port / boost interface, so users of axis can easily use these for their async IO. May be implementing a new transport using Proactor pattern(1) possibly using boost library is a good solution. This is possible since new transports could be plugged into Axis2/C by design. However this will need some changes in op_client implementation because currently for async calls it execute on new threads. However adding this functionality through environment structure seems inappropriate. Also it is not clear to me how to implement it in that way. WDYT?.
Re: Multi-threading
Patrick van Beem wrote: Hello Bill Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the global environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. Correct. I already use these. But afaik the configuration file is read when creating the stub. And that should be done for each thread / call. So while many resources can indeed be shared, the one needing the most (time-consuming) initialization (I think), can't. I think this would be a great improvement for the future. I think adding this functionality to the stub creation is straight forward. Just add the stub creation function axis2_stub_create_with_conf_ctx_and_endpoint_ref_and_client_home(const axutil_env_t * env, axis2_conf_ctx_t *con_ctx, axis2_endpoint_ref_t * endpoint_ref, const axis2_char_t * client_home)); which in turn call already available api function axis2_svc_client_create_with_conf_ctx_and_svc( const axutil_env_t * env, const axis2_char_t * client_home, axis2_conf_ctx_t * conf_ctx, axis2_svc_t * svc); I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. The current implementation of a thread pool in axis is no thread pool but a collection of thread creation and deletion methods... So no... But when creating environment you can pass your own thread pool. Would that not help? thanks, thanks, Damitha Thank you for your input. -- __ Damitha Kumarage http://people.apache.org/ __
Re: RE : Multi-threading
Patrick van Beem wrote: Hello Carl, What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this. Yes, this problem exists in the current implementation. A second callback as you said is the ideal solution. thanks, Damitha Right now, the framework does not provide a safe way of freeing resources in async calls. My reason for responding though is really to comment on this phrase: Threads are a rather expensive resource to use for just waiting on an IO completion. It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long time. Correct. So if I've got a couple of hundred outstanding calls, they all consume precious memory. In our case, this is a lot of memory, since we have a heavy server applications with a greedy memory allocation strategy per thread (for performance) and a rather large default stacks. Of course, both can be optimized for the 'just waiting on io-completion'-threads... CPU-wise, it's no problem. How can one thread wait on more than one asychronous communication? I admit this would be a far better solution, however from my understanding of winsock2 it is not possible. With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports (though a pool of threads might be a good idea if the number of sockets grows large). This is also used by the well known boost (C++) library. Mechanisms like these would be a much better implementation. But I think they don't fit well in the modular (transportation) design of axis, since they require knowledge about the lower level transportation on a higher level. Seen this way, one thread per socket communication is maybe expensive in resources, but it is the only way to ensure your main thread continues to operate in a timely fashion. But prone to explode with a log of async calls. As a 'workaround' I've now my own static-sized thread pool that perform synchronous calls. If there are more async calls then threads in the pool, they're queued. Thank you for your input. -- __ Damitha Kumarage http://people.apache.org/ __
Re: RE : RE : Multi-threading
Hi, Hello Patrick, But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. Yes, this is a pretty serious limitation. I have been trying to find out if Axis2/C provides a way to either know the thread id of the communication threads created internally or to be notified exactly when the threads exit. As you suggest, this is treated as an implementation detail and we are expected to code without a precise notification of when these threads finishes their tasks. It sounds like you would like to free resources on a per-call basis. Is that right? I'm quite new to the Axis2/C architecture so perhaps a more experienced person could suggest a mechanism that would fit into the existing methodology and provide this extra feature. My impression is that the design philosophy so far is to free resources after all calls are completed. Current implementation does not provide a way to free resources on a per-call basis. I agree with Patrick, we should provide a callback to free the resources. Regards, Shankar With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports... But I think they don't fit well in the modular (transportation) design of axis That's very interesting. I'm curious as to more of the details of how this functions... If you have one thread waiting on 12 sockets and want to make a new call, can this thread begin the next call, or does a second thread open the socket and pass the job of waiting on it to the first thread? I think we would all agree that your use case would benefit from adding this capability to Axis2/C. You mention a potential conflict with the modular design of Axis; there is also the idea that making such a powerful feature accessible to the average programmer using Axis could be a challenge. Maybe the solution would be to add a new communication mode instead of changing all asynchronous communication to one-thread-multi-socket. I wish I understood the Axis2/C architecture more fully because this would be an interesting area to contribute. The pleasure is all mine in this conversation. So far I am learning more about winsock :) _ Ce message est confidentiel, a l'usage exclusif du destinataire ci-dessus et son contenu ne represente en aucun cas un engagement de la part de AXA, sauf en cas de stipulation expresse et par ecrit de la part de AXA. Toute publication, utilisation ou diffusion, meme partielle, doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce message, merci d'en avertir immediatement l'expediteur. This e-mail message is confidential, for the exclusive use of the addressee and its contents shall not constitute a commitment by AXA, except as otherwise specifically provided in writing by AXA. Any unauthorized disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately. -- S.Uthaiyashankar Software Architect WSO2 Inc. http://wso2.com/ - The Open Source SOA Company
Re: Multi-threading
Hello Supun, First we need to think why we need to execute Axis2/C clients in multiple threads instead of using separate clients in different threads. I had to read that sentence at least three times before I understood it :-) You mail does shine some light on the subject for me. Both the overhead and performance are an issue for us. And since IO is involved when initializing a stub, performance might be more important. We selected axis for our soap interface because of the adb code generation (ease of use while adding more and more soap clients). So writing a lot of code for the mep instead of 'just using the framework' is not really an option for us. I think we stay with the 'use our own thread pool and do sync calls from there' implementation of 'async' calls for now. Thanks for the input. One advantage of using a single client is the overhead associated with multiple clients. A single axis2_svc_client requires multiple axis2 configurations and multiple environments. This is the only reasong comes to my mind right now for not using different axis2_svc_clients in different threads. If you have any other requirements please share with us. If performance is the concern associated with creating multiple clients, there is a solution to the problem. The real entity that do the most important work in the client side is axis2_mep_client. axis2_svc_client is a wrapper around the mep client for make the job easier for the client programmer. But axis2_svc_client is not designed for a multithreaded environment. The problems with axis2_svc_client running in multiple threads is it keep tracks of the various objects from previous invokations. This leads to double free this resources in multiple threading environments. But if we can use the mep client these problems won't be there. The only problem with mep client is it requires quite a bit of coding to make it work. If we can provide a simple thread safe method set for directly accessing the mep client it will be really useful. So devs what do you think? Supun.. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
RE : RE : Multi-threading
Hello Patrick, But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. Yes, this is a pretty serious limitation. I have been trying to find out if Axis2/C provides a way to either know the thread id of the communication threads created internally or to be notified exactly when the threads exit. As you suggest, this is treated as an implementation detail and we are expected to code without a precise notification of when these threads finishes their tasks. It sounds like you would like to free resources on a per-call basis. Is that right? I'm quite new to the Axis2/C architecture so perhaps a more experienced person could suggest a mechanism that would fit into the existing methodology and provide this extra feature. My impression is that the design philosophy so far is to free resources after all calls are completed. With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports... But I think they don't fit well in the modular (transportation) design of axis That's very interesting. I'm curious as to more of the details of how this functions... If you have one thread waiting on 12 sockets and want to make a new call, can this thread begin the next call, or does a second thread open the socket and pass the job of waiting on it to the first thread? I think we would all agree that your use case would benefit from adding this capability to Axis2/C. You mention a potential conflict with the modular design of Axis; there is also the idea that making such a powerful feature accessible to the average programmer using Axis could be a challenge. Maybe the solution would be to add a new communication mode instead of changing all asynchronous communication to one-thread-multi-socket. I wish I understood the Axis2/C architecture more fully because this would be an interesting area to contribute. The pleasure is all mine in this conversation. So far I am learning more about winsock :) _ Ce message est confidentiel, a l'usage exclusif du destinataire ci-dessus et son contenu ne represente en aucun cas un engagement de la part de AXA, sauf en cas de stipulation expresse et par ecrit de la part de AXA. Toute publication, utilisation ou diffusion, meme partielle, doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce message, merci d'en avertir immediatement l'expediteur. This e-mail message is confidential, for the exclusive use of the addressee and its contents shall not constitute a commitment by AXA, except as otherwise specifically provided in writing by AXA. Any unauthorized disclosure, use or dissemination, either whole or partial, is prohibited. If you are not the intended recipient of the message, please notify the sender immediately.
Re: RE : Multi-threading
Hello Carl, What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this. Right now, the framework does not provide a safe way of freeing resources in async calls. My reason for responding though is really to comment on this phrase: Threads are a rather expensive resource to use for just waiting on an IO completion. It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long time. Correct. So if I've got a couple of hundred outstanding calls, they all consume precious memory. In our case, this is a lot of memory, since we have a heavy server applications with a greedy memory allocation strategy per thread (for performance) and a rather large default stacks. Of course, both can be optimized for the 'just waiting on io-completion'-threads... CPU-wise, it's no problem. How can one thread wait on more than one asychronous communication? I admit this would be a far better solution, however from my understanding of winsock2 it is not possible. With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports (though a pool of threads might be a good idea if the number of sockets grows large). This is also used by the well known boost (C++) library. Mechanisms like these would be a much better implementation. But I think they don't fit well in the modular (transportation) design of axis, since they require knowledge about the lower level transportation on a higher level. Seen this way, one thread per socket communication is maybe expensive in resources, but it is the only way to ensure your main thread continues to operate in a timely fashion. But prone to explode with a log of async calls. As a 'workaround' I've now my own static-sized thread pool that perform synchronous calls. If there are more async calls then threads in the pool, they're queued. Thank you for your input. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
RE: Multi-threading
Hello Bill Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the global environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. Correct. I already use these. But afaik the configuration file is read when creating the stub. And that should be done for each thread / call. So while many resources can indeed be shared, the one needing the most (time-consuming) initialization (I think), can't. I think this would be a great improvement for the future. I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. The current implementation of a thread pool in axis is no thread pool but a collection of thread creation and deletion methods... So no... Thank you for your input. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged or confidential and is the property of Quintiq. It is only intended for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute or use this message or any part thereof. If you have received this message in error, please notify the sender immediately and delete all copies of this message. Please note that e-mails are susceptible to change, therefore they are not binding.
RE: Multi-threading
Patrick, thanks for your other note addressing Supun. I, too, was a little puzzled trying to understand his response, as I had not experienced any instances of crashes/failures from double frees in Axis2c (provided I avoided libxml). Thinking about Supun's comments, I concluded that this must be a difference between sync and async I/O. From your description, the implementation architecture I chose matches yours: a pool of threads performing synchronous I/O. Thus I fortuitously avoided the problem that Carl and you ran into with asynchronous calls, and that you worked around when you went to synchronous calls. Best regards, Bill Mitchell wtmitche...@acm.org -Original Message- From: Patrick van Beem [mailto:patrick.van.b...@quintiq.com] Sent: Tuesday, December 16, 2008 6:20 AM To: Apache AXIS C Developers List Subject: Re: RE : Multi-threading Hello Carl, What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this. Right now, the framework does not provide a safe way of freeing resources in async calls. My reason for responding though is really to comment on this phrase: Threads are a rather expensive resource to use for just waiting on an IO completion. It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long time. Correct. So if I've got a couple of hundred outstanding calls, they all consume precious memory. In our case, this is a lot of memory, since we have a heavy server applications with a greedy memory allocation strategy per thread (for performance) and a rather large default stacks. Of course, both can be optimized for the 'just waiting on io-completion'-threads... CPU-wise, it's no problem. How can one thread wait on more than one asychronous communication? I admit this would be a far better solution, however from my understanding of winsock2 it is not possible. With the fd_set in winsock and the select() function, you can wait at a maximum of 64 (current implementation) sockets at once. With I/O Completion Ports you can use one thread for an infinite number of ports (though a pool of threads might be a good idea if the number of sockets grows large). This is also used by the well known boost (C++) library. Mechanisms like these would be a much better implementation. But I think they don't fit well in the modular (transportation) design of axis, since they require knowledge about the lower level transportation on a higher level. Seen this way, one thread per socket communication is maybe expensive in resources, but it is the only way to ensure your main thread continues to operate in a timely fashion. But prone to explode with a log of async calls. As a 'workaround' I've now my own static-sized thread pool that perform synchronous calls. If there are more async calls then threads in the pool, they're queued. Thank you for your input. -- Patrick van Beem Sr. Software engineer Quintiq T +31 (0) 73 691 07 39 F +31 (0) 73 691 07 54 M +31 (0) 06 15 01 65 83 E patrick.van.b...@quintiq.com I www.quintiq.com This message contains information that may be privileged
Re: Multi-threading
Hi all, This question has being popping up time to time. First we need to think why we need to execute Axis2/C clients in multiple threads instead of using separate clients in different threads. One advantage of using a single client is the overhead associated with multiple clients. A single axis2_svc_client requires multiple axis2 configurations and multiple environments. This is the only reasong comes to my mind right now for not using different axis2_svc_clients in different threads. If you have any other requirements please share with us. If performance is the concern associated with creating multiple clients, there is a solution to the problem. The real entity that do the most important work in the client side is axis2_mep_client. axis2_svc_client is a wrapper around the mep client for make the job easier for the client programmer. But axis2_svc_client is not designed for a multithreaded environment. The problems with axis2_svc_client running in multiple threads is it keep tracks of the various objects from previous invokations. This leads to double free this resources in multiple threading environments. But if we can use the mep client these problems won't be there. The only problem with mep client is it requires quite a bit of coding to make it work. If we can provide a simple thread safe method set for directly accessing the mep client it will be really useful. So devs what do you think? Supun.. On Thu, Dec 11, 2008 at 10:37 PM, Bill Mitchell bmitch...@austin.rr.comwrote: Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the global environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. Good luck, Bill Mitchell -Original Message- From: Lefrancois, Carl [mailto:carl.lefranc...@axa-canada.com] Sent: Thursday, December 11, 2008 9:56 AM To: Apache AXIS C Developers List Subject: RE : Multi-threading Hello Patrick, Manjula kindly provided a best-practice example for how to do multi-threading with Axis2/C [1] (at least on the client side) if I remember correctly, it was one environment per thread, and the stubs were per call? Well in his example it is svc_client and not stub, but if I understand correctly, those two concepts are one-to-one, meaning one stub has one svc_client. From my point of view it seems the troubles you are encountering are based in areas where Axis does little or nothing to help the programmer. I have not seen any code to manage thread creation and resources acces in the Axis2/C project. Problems like resource deadlock on the configuration file are outside the scope of what Axis2/C has to offer. What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. For environment vs stub issues, there is no alternative but to take ownership of this problem directly and implement some synchronisation outside the scope of Axis2/C. Your code synchronises creation of threads and initialisation to avoid having deadlock problems. Maybe there is some improvement to be made to Axis here? My reason for responding though is really to comment on this phrase: Threads are a rather expensive resource to use for just waiting on an IO completion. It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long
Re: Multi-threading
On Sat, 2008-12-13 at 13:02 +0500, Supun Kamburugamuva wrote: Hi all, This question has being popping up time to time. First we need to think why we need to execute Axis2/C clients in multiple threads instead of using separate clients in different threads. One advantage of using a single client is the overhead associated with multiple clients. A single axis2_svc_client requires multiple axis2 configurations and multiple environments. This is the only reasong comes to my mind right now for not using different axis2_svc_clients in different threads. If you have any other requirements please share with us. If performance is the concern associated with creating multiple clients, there is a solution to the problem. The real entity that do the most important work in the client side is axis2_mep_client. Not mep_client it is op_client. axis2_svc_client is a wrapper around the mep client for make the job easier for the client programmer. But axis2_svc_client is not designed for a multithreaded environment. The problems with axis2_svc_client running in multiple threads is it keep tracks of the various objects from previous invokations. This leads to double free this resources in multiple threading environments. But if we can use the mep client these problems won't be there. The only problem with mep client is it requires quite a bit of coding to make it work. If we can provide a simple thread safe method set for directly accessing the mep client it will be really useful. So devs what do you think? Actually AFAIK, even each svc_client_send_receive creates a new op_client and this op_client uses the configurations created from svc_client. So svc_client is like a container which keeps the configurations for the use of op_clients. What we need to do is we should provide methods to application clients to create configurations of their own. So they can pass these to op_client and do the work. Supun.. On Thu, Dec 11, 2008 at 10:37 PM, Bill Mitchell bmitch...@austin.rr.com wrote: Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the global environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. Good luck, Bill Mitchell -Original Message- From: Lefrancois, Carl [mailto:carl.lefranc...@axa-canada.com] Sent: Thursday, December 11, 2008 9:56 AM To: Apache AXIS C Developers List Subject: RE : Multi-threading Hello Patrick, Manjula kindly provided a best-practice example for how to do multi-threading with Axis2/C [1] (at least on the client side) if I remember correctly, it was one environment per thread, and the stubs were per call? Well in his example it is svc_client and not stub, but if I understand correctly, those two concepts are one-to-one, meaning one stub has one svc_client. From my point of view it seems the troubles you are encountering are based in areas where Axis does little or nothing to help the programmer. I have not seen any code to manage thread creation and resources acces in the Axis2/C project. Problems like resource deadlock on the configuration file are outside the scope of what Axis2/C has to offer. What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think
RE: Multi-threading
Patrick, when building a multi-threaded Axis2C client I too was concerned about the multiple environments. Although your statement is correct in a sense that each thread needs its own environment/stub, these environments can in fact share much of the underlying structures. In practice, each thread needs its own error stack, but it can certainly share the allocator and logger. And the configuration information is associated with the allocator. There is a primitive function axutil_env_create_with_error_log_thread_pool() that lets you share the substructures already created for the global environment created once for the application. This way the configuration information is read only once. Axutil_env_free_masked() lets each thread free just its error stack upon termination, leaving the allocator et.al. intact. I was not dealing with asynchronous operation in my application, so I don't know if you might need a separate thread-pool for each created environment. Good luck, Bill Mitchell -Original Message- From: Lefrancois, Carl [mailto:carl.lefranc...@axa-canada.com] Sent: Thursday, December 11, 2008 9:56 AM To: Apache AXIS C Developers List Subject: RE : Multi-threading Hello Patrick, Manjula kindly provided a best-practice example for how to do multi-threading with Axis2/C [1] (at least on the client side) if I remember correctly, it was one environment per thread, and the stubs were per call? Well in his example it is svc_client and not stub, but if I understand correctly, those two concepts are one-to-one, meaning one stub has one svc_client. From my point of view it seems the troubles you are encountering are based in areas where Axis does little or nothing to help the programmer. I have not seen any code to manage thread creation and resources acces in the Axis2/C project. Problems like resource deadlock on the configuration file are outside the scope of what Axis2/C has to offer. What Axis does well is freeing resources (once we figure out how to set everything up right!) so I am a little confused as to where exactly the limitations are. You say the callback system provided is not good in terms of freeing resources, but have you tried freeing your resources from another function which itself waits for the callback to occur? (either error callback or success callback) I think this is the way Axis was designed with as implied by Dimuthu: wait in a loop in your main thread while the callbacks are outstanding, do no cleanup in the callback itself, let that thread exit completely and after it is done, then from your main thread detect that the callback ocurred and do the cleanup there. For environment vs stub issues, there is no alternative but to take ownership of this problem directly and implement some synchronisation outside the scope of Axis2/C. Your code synchronises creation of threads and initialisation to avoid having deadlock problems. Maybe there is some improvement to be made to Axis here? My reason for responding though is really to comment on this phrase: Threads are a rather expensive resource to use for just waiting on an IO completion. It may be my lack of understanding, but I am pretty sure that -- at least in the win32 tcp/ip stack -- once your thread goes into asynchronous communication on a socket, you do not see it again until there is some result. This means if there is a timeout your thread is inactive for a long time. How can one thread wait on more than one asychronous communication? I admit this would be a far better solution, however from my understanding of winsock2 it is not possible. Seen this way, one thread per socket communication is maybe expensive in resources, but it is the only way to ensure your main thread continues to operate in a timely fashion. Hth Carl [1] http://marc.info/?l=axis-c-userm=118404667311058w=2 -Message d'origine- De : Patrick van Beem [mailto:patrick.van.b...@quintiq.com] Envoyé : jeudi, décembre 11, 2008 05:46 À : axis-c-dev@ws.apache.org Objet : Multi-threading Hello, I'm experiencing serious limitations while using axis in a multi-threading environment. I know axis is not fully designed (yet?) for multi-threading, but I think some 'small' changes might make it more usable. One can't deny multi-threading. Here my 2 cents: * Callback and resources In a multi-threading environment, an asynchronous job is often responsible for freeing it's own resources (in this case, the environment, the stub and possible extra application dependent data). In the axis framework, this can't be done in the callback, since the framework will use the stub after the callback is finished. This makes it impossible for an application to free resources after a call has finished (because you never know exactly when the call (including the framework part of it) is finished. This makes the asynchronous implementation of axis useless in a job-oriented multi-threading environment. Improvements
Re: Multi threading in Axis2/C
Baxi, Rinilkumar (TCS) [EMAIL PROTECTED] writes: Hello, I have been looking at the Axis2/C code. Axis configuration files indicate that Axis supports multi threading. It appears at first glance that it is the HTTP listener (in transport phase) which provides multi threading support. And the rest of Axis(Axis engine, message receiver) is single threaded. Kindly let me know whether my understanding is correct. AFAIK, your understanding is correct. Axis2/C engine is designed to be operated single threaded in multi threading environment, that is why we could see using mutexes in op_ctx and conf_ctx. thanks, Dinesh -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multi threading in Axis2/C
Hello Rinil, I see two aspects to the multi-threading question, whether Axis2C runs in a multi-threaded environment, and whether Axis2C itself takes advantage of a multi-threading. My experience has been on the client side; it seems your question may be on the server side, with which I am much less familiar. What I can tell you is that Axis2C can be used successfully in a multithreaded client. The key is that the processing is done in the context of an axutil environment structure. What I found is that I can share one axis configuration across multiple threads by creating multiple environments that share the same allocator and logger while each use their own axutil error handler. The separate error handler is needed so that each thread sees only its own errors, not errors that appear in another thread. Sharing the allocator allows the configuration to be processed only once for the client app, instead of being processed as each thread is initialized. So, in this case, Axis2C client is running in a multithreaded environment, without taking any particular advantage of multithreading itself. Perhaps someone else can shed some light your question about the message receiver. Enjoy, Bill -Original Message- From: Baxi, Rinilkumar (TCS) [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 6:19 AM To: Apache AXIS C Developers List Subject: Multi threading in Axis2/C Hello, I have been looking at the Axis2/C code. Axis configuration files indicate that Axis supports multi threading. It appears at first glance that it is the HTTP listener (in transport phase) which provides multi threading support. And the rest of Axis(Axis engine, message receiver) is single threaded. Kindly let me know whether my understanding is correct. Also I'd like to know if its feasible to introduce multi threading in the message receiver. Thanks and Regards, Rinil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi threading in Axis2/C
On Fri, 2008-05-16 at 11:19 +, Baxi, Rinilkumar (TCS) wrote: Hello, I have been looking at the Axis2/C code. Axis configuration files indicate that Axis supports multi threading. It appears at first glance that it is the HTTP listener (in transport phase) which provides multi threading support. And the rest of Axis(Axis engine, message receiver) is single threaded. Kindly let me know whether my understanding is correct. Also I'd like to know if its feasible to introduce multi threading in the message receiver. You may need to write your own message_receiver in the case. [1] is an example of a custom message receiver. Thanks, -Manjula. [1]https://wso2.org/repos/wso2/trunk/wsf/php/src/wsf_xml_msg_recv.c Thanks and Regards, Rinil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
