Hudson build is back to stable: Synapse - Trunk » Apache Synapse - Transports #538
See http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-transports/538/ - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: startup order - correct place to start transport listeners
Indika, I agree with you, but what we are considering is the same as this explanation. We do not want to kept the listener initialization till we initialize rest of the components. For the moment what happens is basically, while we initialize the components messages can flow into these components because the listeners are already started to accept the messages, which is completely wrong because the initialization of the application layer is halfway through. So this is a matter of clearly differentiating the initialization from the starting process. So even though the listeners are initialized they shouldn't accept messages till the application layer (i.e. components or the Synapse Env) signals the ready state. I am trying to come up with a proposal to implement this. When we do a considerable change, it is better to discuss things before commiting to implement that even though we are operating on CTR model. Thanks, Ruwan On Fri, Apr 3, 2009 at 11:02 AM, indika kumara wrote: > Hi all > > I didn’t care much about stop order. It’s my wrong. Thanks for correcting > it. > > But, I strongly feel, what need is correct implementation of graceful > start and shutdown semantic and integrate it. > > When build a something top on a based - a layered approach. > > Initializing process is going upward and showdown process is going > downward. When creating a layer top on another layer, base layer > should not call any functions on currently being building uppperlayer > but should allow downward call from upper layer. Only after correctly > build the upper layer, upward channel should open. > > Shutdown process should begin with signaling lower layers to cutoff > the upward channel and but accept downward calls. Only, after > completely has been showdown upper layer, down layer should cutoff > downward channel. Destroying base layer at first is bad solution. > > Considering synapse is in application layer and transport handling > components is in transport layer. Initialization should begin with > transport layer. On initialization, the transport layer should not > accept any requests received (cutoff upward channel) and call > functions in application layer, until application layer components > tell (by event) that open upward channel. But, downward channel should > be opened at anytime. In shutdown process, application should tell > transport to change the mode so that cutoff upward channel but remain > open downward and then begin to properly showdown application > components and only after that tell transport to cutoff downward > channel and to make shutdown complete. > > Only a solution that implement semantic such as above will work. > Solutions without semantic are definitely tricks. > > I can remind, there was a trick to cope with early start of listeners. > Synapse configuration (endpoint , proxy , startup , endpoint, etc) was > initialized with synapse environment that have set to initialized > ‘false’ and then start listeners and then set synapse environment to > initialized ‘true’ and call ‘startup’ initialization. This only shows > a design flaws. If proper initialization semantic was preserved > (during initialization top layer can talk (can request) to down layer > but down layer cannot talk (no request) to upper layer), this kind of > trick that something get to work was really not needed. > > Calling listener showdown before applications components are shutting > down, is bad solution. If the transport has been shut down, what if > any application component that still ruing is needed transport - for > example running task …Anyway destroying base before components top on > base is bad design principle. Here, graceful showdown semantic of > system (not just transport) has not been preserved. Shutting down > should begin with notifying base that I am going to shutdown so that > base can cut off upward channel (transport doesn’t accept new request > and but accept results from applications )) but remain open the > downward channel. Then, application can safely shout down. After > completing shutdown, it can notify base to cutoff the down channel and > complete shut down. > > For a sophisticate graceful start and shutdown semantic, components > relationship within any layers may need to include. (What if a > sequence is referred by another sequence and that reference sequence > has been destroying while it is being used.) > > Anything without semantic is a trick - something I never like. > > Thanks > Indika > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: startup order - correct place to start transport listeners
Hi Indika We already have the capability to shutdown gracefully, or on demand. In a graceful shutdown request, we first turn off accepting new messages. But continue processing already accepted and processing messages. So the messages already in the engine can work normally, send out requests, accept responses etc. The transport listeners (e.g. HTTP/S) are also up.. and once responses are ready on open sockets, they would still continue to send back responses to the clients that are still connected. Its only new requests that are stopped. I wrote the code to get the engine to wait a maximum number of seconds - for these in-process messages to complete, the callbacks to get replies etc. However, once the graceful timeout specified by a user expires, we shutdown the engine. This code is already within the WSO2 ESB 1.7.x and is valid for Synapse to be brought in cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: startup order - correct place to start transport listeners
Hi all I didn’t care much about stop order. It’s my wrong. Thanks for correcting it. But, I strongly feel, what need is correct implementation of graceful start and shutdown semantic and integrate it. When build a something top on a based - a layered approach. Initializing process is going upward and showdown process is going downward. When creating a layer top on another layer, base layer should not call any functions on currently being building uppperlayer but should allow downward call from upper layer. Only after correctly build the upper layer, upward channel should open. Shutdown process should begin with signaling lower layers to cutoff the upward channel and but accept downward calls. Only, after completely has been showdown upper layer, down layer should cutoff downward channel. Destroying base layer at first is bad solution. Considering synapse is in application layer and transport handling components is in transport layer. Initialization should begin with transport layer. On initialization, the transport layer should not accept any requests received (cutoff upward channel) and call functions in application layer, until application layer components tell (by event) that open upward channel. But, downward channel should be opened at anytime. In shutdown process, application should tell transport to change the mode so that cutoff upward channel but remain open downward and then begin to properly showdown application components and only after that tell transport to cutoff downward channel and to make shutdown complete. Only a solution that implement semantic such as above will work. Solutions without semantic are definitely tricks. I can remind, there was a trick to cope with early start of listeners. Synapse configuration (endpoint , proxy , startup , endpoint, etc) was initialized with synapse environment that have set to initialized ‘false’ and then start listeners and then set synapse environment to initialized ‘true’ and call ‘startup’ initialization. This only shows a design flaws. If proper initialization semantic was preserved (during initialization top layer can talk (can request) to down layer but down layer cannot talk (no request) to upper layer), this kind of trick that something get to work was really not needed. Calling listener showdown before applications components are shutting down, is bad solution. If the transport has been shut down, what if any application component that still ruing is needed transport - for example running task …Anyway destroying base before components top on base is bad design principle. Here, graceful showdown semantic of system (not just transport) has not been preserved. Shutting down should begin with notifying base that I am going to shutdown so that base can cut off upward channel (transport doesn’t accept new request and but accept results from applications )) but remain open the downward channel. Then, application can safely shout down. After completing shutdown, it can notify base to cutoff the down channel and complete shut down. For a sophisticate graceful start and shutdown semantic, components relationship within any layers may need to include. (What if a sequence is referred by another sequence and that reference sequence has been destroying while it is being used.) Anything without semantic is a trick - something I never like. Thanks Indika - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: VFS Text Files with spaces don't work.
You are probably right. Haven't had time to look but I hope the payload "text" element is defined as space="preserve". If yes then its OK, If not then ? Any idea where is the XSD is easily available ? It is probably one of the mediators removing the white space along the way; as XML does not preserve this. I will have to add in yet again more java to wrap the text field in CDATA "". As the recipient cannot change their XSD, this looks like the only optionNot sure XSLT will work unless target name space also defines the element as space preserve ? My simple Synapse script is becoming a massive Java program. And I thought "wouldn't it be easy to use a scripting tool like Synapse compared to writing Java code ". How wrong. Thanks Kim Andreas Veithen-2 wrote: > > Are you sure that these spaces get trimmed inside the VFS transport > and not somewhere in your mediation? Normally the plain text message > builder is designed to strictly preserve the file content (including > spaces), so this would be a serious bug. > > Andreas > > On Thu, Apr 2, 2009 at 08:52, kimhorn wrote: >> >> Run into a problem with VFS reading text files with fixed field length >> fields, where empty fields are padded with spaces. There are a number of >> B2B >> formats that do this. >> >> If the empty fields are at the start or end of the file then when these >> are >> inserted into XML as Payload the >> XML removes the spaces. The text should be wrapped in CDATA with double >> Quotes to preserve this space data; but VFS does not do this. So the >> fields >> at start or end of file get lost and hence the whole file is now garbage. >> >> Hopefully reading them as binary files (not plan text) will get over this >> ? >> Other ideas ? >> >> >> -- >> View this message in context: >> http://www.nabble.com/VFS-Text-Files-with-spaces-don%27t-work.-tp22841970p22841970.html >> Sent from the Synapse - Dev mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > > -- View this message in context: http://www.nabble.com/VFS-Text-Files-with-spaces-don%27t-work.-tp22841970p22862146.html Sent from the Synapse - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Hudson build became unstable: Synapse - Trunk » Apache Synapse - Transports #537
See http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-transports/537/ - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Exception handling
Hi Eric, I think logging an exception with the context information (i.e. with a message describing the possible cause for this) would be of very much useful when it comes to the stack trace analysis so that by just looking at the log we can exactly find what went wrong. We are not just wrapping the exception in a SynapseException but also this SynapseException provides more information about the cause, again this is about the context of the error. Thanks, Ruwan On Thu, Apr 2, 2009 at 3:13 PM, Hubert, Eric wrote: > Hi Synapse devs, > > No worries, I don't want to start a discussion about exception handling in > general, I just would like to understand the reasoning of your design > choice. I stumbled over some areas in the code where I noticed that an > original exception is caught, logged AND rethrown wrapped inside a > SynapseException or SynapseUtilException (specific RuntimeExceptions). The > original exception is then mostly logged as an error, no matter whether the > caller may consider the exception to be critical or easily recoverable. If > he is able to recover, the original problem is already logged as an error > and he may only add a warning about the way he could recover. > > The good thing is that the almost the whole code looks pretty consistent in > this regard and I bet this is due to the following comment > "We always log each exception the first time it is caught, and throw a > SynapseException with an appropriate error message that tries to give out > additional information on why the exception occurred." > in the developer guidelines at > http://cwiki.apache.org/synapse/developer-guidelines.html (Would it make > sense to make this guideline easier available? Integrate or link it from the > main page?). > > What is the reasoning of this exception handling/logging approach? > > So far I was used to the following rule(s): > Either throw (chaining/wrapping of original exception) or log, except on > component boundaries where original exceptions have to be logged AND new > exceptions created and thrown (no chaining/wrapping of original exception > for this case, as implementation details and concrete stack/dependencies > shall be hidden from the caller). So far I never had problems with this > approach. What are other's experiences? > > Of course I will follow the chosen approach - this is more out of personal > interest. > > Regards, > Eric > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: startup order - correct place to start transport listeners
On Thu, Apr 2, 2009 at 7:07 PM, Hubert, Eric wrote: > Makes perfectly sense Ruwan, and I did think about it as a seconds step > as well! Just wanted to mention it, as from a user’s perspective the same > problems which may arise at startup can also arise at shutdown. And once > something is fresh in memory, those changes are easier to perform. Thanks > for taking the time for improving this. > > Once you are done, I’m of course willing to do a review. > +1 Ruwan > > > Thanks, > >Eric > > > > > -- > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Thursday, April 02, 2009 2:51 PM > > *To:* dev@synapse.apache.org > *Subject:* Re: startup order - correct place to start transport listeners > > > > Eric, > > I agree with the comments and I will be looking into the start order first > to address your issue, and then I will change the stop process in a way that > it does exactly the opposite. If we change it now and had to change it after > fixing the start order that is going to be a double work for the stop > process. > > Thanks, > Ruwan > > On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric > wrote: > > Hi Ruwan, > > > > thanks for taking the time to review the startup/shutdown logic > implemented. In terms of structure and readability I also widely liked the > changes. I have only those real world usage’s concerns. So if you are > already at it could you please also look at the shutdown process! > > In most situations the correct shutdown order is exactly the opposite of > the startup order. And honestly, this is what I also would expect here. > > > > Specifically please have a look at ServerManager.doStart() versus > ServerManager.doStop()! > > > > Start: > > Create Synapse Configuration > > Create Synapse Environment > > > > Stop: > > Destroy Synapse Configuration > > Destroy Synapse Environment > > Destroy ß only here listeners will be stopped (in the mean time the > instance keeps accepting requests which can’t be processed as everything > else has already been stopped/deactivated) > > > > To me this looks wrong. > > > > Regards, > >Eric > > > -- > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Thursday, April 02, 2009 3:59 AM > > > *To:* dev@synapse.apache.org > *Subject:* Re: startup order - correct place to start transport listeners > > > > I went through the new synapse startup logic and it seems OK but this makes > the following concrete changes to the synapse architecture > >- Synapse can no longer be deployed just as a pure module in axis2, it >requires much more work. >- The message mediation is restricted to HTTP and HTTPS, which I am not >sure whether we want to keep it as it is. > > But still this new logic even doesn't address the original problem in the > discussion. In the new logic transport listeners starts even before the > mediators getting loaded into synapse. > > I think we need to improve this, and to me Eric's point is completely a > valid point. I will further look into resolving this and will keep the list > posted. > > > > > -- > Ruwan Linton > Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: Exception handling
Hi Eric thanks for your reply. Humans life would be to boring, if we would always share the same opinion. ;-) Of course I may be wrong too and in some cases we maybe able to improve the code we already have, and I am fully open to change which is good for the project :-) Item 43: Throw exceptions appropriate to the abstraction This is very, very important. And at this point I would rather also like to add, that one sometimes should also take care to not violate this indirectly via chaining the cause which brings along all the details which should be abstracted. That's via a favour to create new exceptions at that point a properly the details at the abstraction boarder. For Synapse, I am not sure I fully agree.. since the main dependency with Axis2 sorts of causes this.. see we get messages from transports, into Axis2, then to Synapse for mediation, then again through Axis2 to transports and out etc.. I do not think keeping the original cause should be abstracted, but left as-is for easier problem resolution via logs etc. Ok, if you decide that you can handle this exception accordingly, I totally agree. But in this case why should you rethrow it? If you can't handle it and decide the caller might be able to handle it (not arguing about checked or unchecked at this point at all to concentrate on one topic), you can't log the error as it might be not a real problem for the caller which may be able to compensate. Logging some general context info for later correlation is another topic. This way you also avoid logging the same exception a couple of times, as the caller can't know whether something has already been logged and from his perspective it is the first time he is catching this exception. I don't think you use the SynapseException only for wrapping, but also for "self created" exceptions, or? Another one from Joshua "..To avoid this problem, higher layers should catch lower-level exceptions and, in their place, throw exceptions that are explainable in terms of the higher-level abstraction." - note that no where in the code do we catch a SynapseException and log or re-throw it.. thats bound by developer discipline so that each exception is only uniquely logged once with most of the information about its cause. Within the Synapse code I do not think there is any outside layer that is able to handle something the Synapse layer beneath could have handled.. I think we need to dig into the code and take some concrete examples, and see if we can really improve things with an alternative, and if we can definitely improve it Anyway it looks like there has already been some discussion about it and I do not want to change something about, just make sure I'm not missing a very special reason. ;-) No discussion is always good, and questioning to improve what we have .. I think best is to keep an eye for something related to exception handling we could improve when we next look at some piece of code, and then take it up for discussion/dissection and more analysis with everyone.. :-) cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com
RE: startup order - correct place to start transport listeners
Makes perfectly sense Ruwan, and I did think about it as a seconds step as well! Just wanted to mention it, as from a user’s perspective the same problems which may arise at startup can also arise at shutdown. And once something is fresh in memory, those changes are easier to perform. Thanks for taking the time for improving this. Once you are done, I’m of course willing to do a review. Thanks, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Thursday, April 02, 2009 2:51 PM To: dev@synapse.apache.org Subject: Re: startup order - correct place to start transport listeners Eric, I agree with the comments and I will be looking into the start order first to address your issue, and then I will change the stop process in a way that it does exactly the opposite. If we change it now and had to change it after fixing the start order that is going to be a double work for the stop process. Thanks, Ruwan On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric wrote: Hi Ruwan, thanks for taking the time to review the startup/shutdown logic implemented. In terms of structure and readability I also widely liked the changes. I have only those real world usage’s concerns. So if you are already at it could you please also look at the shutdown process! In most situations the correct shutdown order is exactly the opposite of the startup order. And honestly, this is what I also would expect here. Specifically please have a look at ServerManager.doStart() versus ServerManager.doStop()! Start: Create Synapse Configuration Create Synapse Environment Stop: Destroy Synapse Configuration Destroy Synapse Environment Destroy <-- only here listeners will be stopped (in the mean time the instance keeps accepting requests which can’t be processed as everything else has already been stopped/deactivated) To me this looks wrong. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Thursday, April 02, 2009 3:59 AM To: dev@synapse.apache.org Subject: Re: startup order - correct place to start transport listeners I went through the new synapse startup logic and it seems OK but this makes the following concrete changes to the synapse architecture * Synapse can no longer be deployed just as a pure module in axis2, it requires much more work. * The message mediation is restricted to HTTP and HTTPS, which I am not sure whether we want to keep it as it is. But still this new logic even doesn't address the original problem in the discussion. In the new logic transport listeners starts even before the mediators getting loaded into synapse. I think we need to improve this, and to me Eric's point is completely a valid point. I will further look into resolving this and will keep the list posted. -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
RE: Exception handling
Hi Asankha, thanks for your reply. Humans life would be to boring, if we would always share the same opinion. ;-) > This basically follows some ideas from Joshua Bloch (Effective Java: > Programming Language Guide), and some discussions on the use of checked > exceptions vs runtime exceptions. Ah, cool. I also read Josh's books and followed a lot of those discussions. > Item 40:Use checked exceptions for recoverable conditions and run-time > exceptions for programming errors I agree with this. > Item 41:Avoid unnecessary use of checked exceptions Also agreed, although it is sometimes not that easy to correctly foresee whether the caller might be able to recover or not. In case of uncertainty I tend to assume the first. > Item 43: Throw exceptions appropriate to the abstraction This is very, very important. And at this point I would rather also like to add, that one sometimes should also take care to not violate this indirectly via chaining the cause which brings along all the details which should be abstracted. That's via a favour to create new exceptions at that point a properly the details at the abstraction boarder. > I personally follow logging of an Exception the first time you find out > about it (i.e. thrown from an external system to you), or you throwing > an exception - so that most of the context information about the > exception could be logged for analysis. Ok, if you decide that you can handle this exception accordingly, I totally agree. But in this case why should you rethrow it? If you can't handle it and decide the caller might be able to handle it (not arguing about checked or unchecked at this point at all to concentrate on one topic), you can't log the error as it might be not a real problem for the caller which may be able to compensate. Logging some general context info for later correlation is another topic. This way you also avoid logging the same exception a couple of times, as the caller can't know whether something has already been logged and from his perspective it is the first time he is catching this exception. I don't think you use the SynapseException only for wrapping, but also for "self created" exceptions, or? > Most of the cases where a > SynapseException is thrown are unrecoverable situations - since many are > dependent on a myriad of causes stemming from AxisFaults.. There are Hmm, you know the code for sure better, but I know for sure that this is at least sometimes not the case. Anyway it looks like there has already been some discussion about it and I do not want to change something about, just make sure I'm not missing a very special reason. ;-) Regards, Eric
Re: startup order - correct place to start transport listeners
Well, we had two operation models called proxy service mediation and message mediation. In the earlier case message is going to be dispatched to the respective proxy service where as in the later case message will be directed to the main sequence. Now the message mediation operational model is only available for the HTTP/S >From my POV this is conceptually wrong with the initial design of synapse. Do we want to drop in the message mediation. Thanks, Ruwan On Thu, Apr 2, 2009 at 1:35 PM, Andreas Veithen wrote: > I guess the HTTP(S) restriction is there for the case where Synapse is > used as an HTTP proxy. I don't see how we would get a similar behavior > with any other transport, so this actually looks right (but should be > better documented in the code). > > Andreas > > On Thu, Apr 2, 2009 at 07:59, Ruwan Linton wrote: > > Yes, I fixed the handler module but what I am referring is the normal > > synapse behavior, not the handler module. > > > > For the message mediation case I think we shouldn't restrict the > transports. > > > > Thanks, > > Ruwan > > > > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara > wrote: > >> > >> Hi Runwan > >> > >> HTTP and HTTPS for synapse message mediation (_SynapseService) > >> setting was there in the previous code (Proxy service only had the per > >> service transports ) . I actually only did refractor - cut and paste > >> and change only organization. Synapse as Handler module can be > >> deployed without much effort... may three , four line > >> > >> Thanks > >> Indika > >> > >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton > >> wrote: > >> > I went through the new synapse startup logic and it seems OK but this > >> > makes > >> > the following concrete changes to the synapse architecture > >> > > >> > Synapse can no longer be deployed just as a pure module in axis2, it > >> > requires much more work. > >> > The message mediation is restricted to HTTP and HTTPS, which I am not > >> > sure > >> > whether we want to keep it as it is. > >> > > >> > But still this new logic even doesn't address the original problem in > >> > the > >> > discussion. In the new logic transport listeners starts even before > the > >> > mediators getting loaded into synapse. > >> > > >> > I think we need to improve this, and to me Eric's point is completely > a > >> > valid point. I will further look into resolving this and will keep the > >> > list > >> > posted. > >> > > >> > Thanks, > >> > Ruwan > >> > > >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva < > supu...@gmail.com> > >> > wrote: > >> >> > >> >> Hi Indika, > >> >> > >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara < > indika.k...@gmail.com> > >> >> wrote: > >> >>> > >> >>> If the synapse is run top on axis2 or any other, it should be > properly > >> >>> initialized and started before initialize synapse. > >> >> > >> >> > >> >> We are talking about two things here. Initialization and startup. I > >> >> agree > >> >> synapse should inilialize after axis2. Also Synapse should start > after > >> >> Axis2. But at the moment it seems that Synapse is starting even > before > >> >> it > >> >> initializes. The way Synapse is written it is perfectly normal to > >> >> assume > >> >> that it is started when Axis2 is started. But if we do it in the > >> >> current > >> >> way, this assumption is broken and can lead to failures as Eric said. > >> >> If > >> >> Axis2 is initialize properly we can initialize Synapse. As Eric said > if > >> >> both > >> >> are successfully initialized we can start Axis2 transports, which > >> >> automatically starts Synapse. > >> >> > >> >> Thanks, > >> >> Supun. > >> >> > >> >> > >> >>> > >> >>> It is a well known > >> >>> semantic that system should be in consistent state before use it. > You > >> >>> can refer [1] and it says why I did. > >> >> > >> >> > >> >> > >> >> > >> >>> > >> >>> The way message get in to synapse and mediation engine (main > behavior) > >> >>> are two different aspects and definitely should have two different > >> >>> decision designs as it is wrong if main behavior depend on other > >> >>> behavior. The starting, shutdown --- simply state (consistent) > >> >>> management of mediation should not depend any thing. Axis2 Hander > is > >> >>> make way to get message into in to synapse and for good design, > >> >>> mediation engine should separate from this design decision. Managing > >> >>> mediation engine should be independent from axis2 or any other. > >> >>> > >> >>> If it is needed to avoid effect of started listeners if the synapse > >> >>> mediation engine started up is failed, then only applicable > >> >>> transaction semantic is compensation transaction. In order to > enforce > >> >>> that, it is needed to properly shutdown listeners, etc --- some how > >> >>> need to move into a consistent state before system startup. > >> >>> > >> >>> [1] > http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html > >> >>> > >> >>> Thanks > >> >>> Indika > >
Re: startup order - correct place to start transport listeners
Eric, I agree with the comments and I will be looking into the start order first to address your issue, and then I will change the stop process in a way that it does exactly the opposite. If we change it now and had to change it after fixing the start order that is going to be a double work for the stop process. Thanks, Ruwan On Thu, Apr 2, 2009 at 2:17 PM, Hubert, Eric wrote: > Hi Ruwan, > > > > thanks for taking the time to review the startup/shutdown logic > implemented. In terms of structure and readability I also widely liked the > changes. I have only those real world usage’s concerns. So if you are > already at it could you please also look at the shutdown process! > > In most situations the correct shutdown order is exactly the opposite of > the startup order. And honestly, this is what I also would expect here. > > > > Specifically please have a look at ServerManager.doStart() versus > ServerManager.doStop()! > > > > Start: > > Create Synapse Configuration > > Create Synapse Environment > > > > Stop: > > Destroy Synapse Configuration > > Destroy Synapse Environment > > Destroy ß only here listeners will be stopped (in the mean time the > instance keeps accepting requests which can’t be processed as everything > else has already been stopped/deactivated) > > > > To me this looks wrong. > > > > Regards, > >Eric > > > -- > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Thursday, April 02, 2009 3:59 AM > *To:* dev@synapse.apache.org > *Subject:* Re: startup order - correct place to start transport listeners > > > > I went through the new synapse startup logic and it seems OK but this makes > the following concrete changes to the synapse architecture > >- Synapse can no longer be deployed just as a pure module in axis2, it >requires much more work. >- The message mediation is restricted to HTTP and HTTPS, which I am not >sure whether we want to keep it as it is. > > But still this new logic even doesn't address the original problem in the > discussion. In the new logic transport listeners starts even before the > mediators getting loaded into synapse. > > I think we need to improve this, and to me Eric's point is completely a > valid point. I will further look into resolving this and will keep the list > posted. > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: Exception handling
Hi Eric I stumbled over some areas in the code where I noticed that an original exception is caught, logged AND rethrown wrapped inside a SynapseException or SynapseUtilException (specific RuntimeExceptions). The original exception is then mostly logged as an error, no matter whether the caller may consider the exception to be critical or easily recoverable. If he is able to recover, the original problem is already logged as an error and he may only add a warning about the way he could recover. The good thing is that the almost the whole code looks pretty consistent in this regard and I bet this is due to the following comment "We always log each exception the first time it is caught, and throw a SynapseException with an appropriate error message that tries to give out additional information on why the exception occurred." in the developer guidelines at http://cwiki.apache.org/synapse/developer-guidelines.html (Would it make sense to make this guideline easier available? Integrate or link it from the main page?). What is the reasoning of this exception handling/logging approach? So far I was used to the following rule(s): Either throw (chaining/wrapping of original exception) or log, except on component boundaries where original exceptions have to be logged AND new exceptions created and thrown (no chaining/wrapping of original exception for this case, as implementation details and concrete stack/dependencies shall be hidden from the caller). So far I never had problems with this approach. What are other's experiences? Of course I will follow the chosen approach - this is more out of personal interest. This basically follows some ideas from Joshua Bloch (Effective Java: Programming Language Guide), and some discussions on the use of checked exceptions vs runtime exceptions. Item 40:Use checked exceptions for recoverable conditions and run-time exceptions for programming errors Item 41:Avoid unnecessary use of checked exceptions Item 43: Throw exceptions appropriate to the abstraction I personally follow logging of an Exception the first time you find out about it (i.e. thrown from an external system to you), or you throwing an exception - so that most of the context information about the exception could be logged for analysis. Most of the cases where a SynapseException is thrown are unrecoverable situations - since many are dependent on a myriad of causes stemming from AxisFaults.. There are places in the code where we catch these, and handle error recovery etc, where appropriate. If we know we can recover from some some types of errors (e.g. transport reconnects etc) we do that too.. cheers asankha [1] http://www.ibm.com/developerworks/java/library/j-jtp05254.html [2] http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Hudson build is back to normal: Synapse - Trunk » Apache Synapse - Transports #535
See http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-transports/535/ - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Exception handling
Interesting question. Personally, I've always considered the log and throw approach as an anti-pattern. Andreas On Thu, Apr 2, 2009 at 11:43, Hubert, Eric wrote: > Hi Synapse devs, > > No worries, I don't want to start a discussion about exception handling in > general, I just would like to understand the reasoning of your design choice. > I stumbled over some areas in the code where I noticed that an original > exception is caught, logged AND rethrown wrapped inside a SynapseException or > SynapseUtilException (specific RuntimeExceptions). The original exception is > then mostly logged as an error, no matter whether the caller may consider the > exception to be critical or easily recoverable. If he is able to recover, the > original problem is already logged as an error and he may only add a warning > about the way he could recover. > > The good thing is that the almost the whole code looks pretty consistent in > this regard and I bet this is due to the following comment > "We always log each exception the first time it is caught, and throw a > SynapseException with an appropriate error message that tries to give out > additional information on why the exception occurred." > in the developer guidelines at > http://cwiki.apache.org/synapse/developer-guidelines.html (Would it make > sense to make this guideline easier available? Integrate or link it from the > main page?). > > What is the reasoning of this exception handling/logging approach? > > So far I was used to the following rule(s): > Either throw (chaining/wrapping of original exception) or log, except on > component boundaries where original exceptions have to be logged AND new > exceptions created and thrown (no chaining/wrapping of original exception for > this case, as implementation details and concrete stack/dependencies shall be > hidden from the caller). So far I never had problems with this approach. What > are other's experiences? > > Of course I will follow the chosen approach - this is more out of personal > interest. > > Regards, > Eric > - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Exception handling
Hi Synapse devs, No worries, I don't want to start a discussion about exception handling in general, I just would like to understand the reasoning of your design choice. I stumbled over some areas in the code where I noticed that an original exception is caught, logged AND rethrown wrapped inside a SynapseException or SynapseUtilException (specific RuntimeExceptions). The original exception is then mostly logged as an error, no matter whether the caller may consider the exception to be critical or easily recoverable. If he is able to recover, the original problem is already logged as an error and he may only add a warning about the way he could recover. The good thing is that the almost the whole code looks pretty consistent in this regard and I bet this is due to the following comment "We always log each exception the first time it is caught, and throw a SynapseException with an appropriate error message that tries to give out additional information on why the exception occurred." in the developer guidelines at http://cwiki.apache.org/synapse/developer-guidelines.html (Would it make sense to make this guideline easier available? Integrate or link it from the main page?). What is the reasoning of this exception handling/logging approach? So far I was used to the following rule(s): Either throw (chaining/wrapping of original exception) or log, except on component boundaries where original exceptions have to be logged AND new exceptions created and thrown (no chaining/wrapping of original exception for this case, as implementation details and concrete stack/dependencies shall be hidden from the caller). So far I never had problems with this approach. What are other's experiences? Of course I will follow the chosen approach - this is more out of personal interest. Regards, Eric
RE: startup order - correct place to start transport listeners
Hi Ruwan, thanks for taking the time to review the startup/shutdown logic implemented. In terms of structure and readability I also widely liked the changes. I have only those real world usage’s concerns. So if you are already at it could you please also look at the shutdown process! In most situations the correct shutdown order is exactly the opposite of the startup order. And honestly, this is what I also would expect here. Specifically please have a look at ServerManager.doStart() versus ServerManager.doStop()! Start: Create Synapse Configuration Create Synapse Environment Stop: Destroy Synapse Configuration Destroy Synapse Environment Destroy <-- only here listeners will be stopped (in the mean time the instance keeps accepting requests which can’t be processed as everything else has already been stopped/deactivated) To me this looks wrong. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Thursday, April 02, 2009 3:59 AM To: dev@synapse.apache.org Subject: Re: startup order - correct place to start transport listeners I went through the new synapse startup logic and it seems OK but this makes the following concrete changes to the synapse architecture * Synapse can no longer be deployed just as a pure module in axis2, it requires much more work. * The message mediation is restricted to HTTP and HTTPS, which I am not sure whether we want to keep it as it is. But still this new logic even doesn't address the original problem in the discussion. In the new logic transport listeners starts even before the mediators getting loaded into synapse. I think we need to improve this, and to me Eric's point is completely a valid point. I will further look into resolving this and will keep the list posted.
Re: startup order - correct place to start transport listeners
I guess the HTTP(S) restriction is there for the case where Synapse is used as an HTTP proxy. I don't see how we would get a similar behavior with any other transport, so this actually looks right (but should be better documented in the code). Andreas On Thu, Apr 2, 2009 at 07:59, Ruwan Linton wrote: > Yes, I fixed the handler module but what I am referring is the normal > synapse behavior, not the handler module. > > For the message mediation case I think we shouldn't restrict the transports. > > Thanks, > Ruwan > > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara wrote: >> >> Hi Runwan >> >> HTTP and HTTPS for synapse message mediation (_SynapseService) >> setting was there in the previous code (Proxy service only had the per >> service transports ) . I actually only did refractor - cut and paste >> and change only organization. Synapse as Handler module can be >> deployed without much effort... may three , four line >> >> Thanks >> Indika >> >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton >> wrote: >> > I went through the new synapse startup logic and it seems OK but this >> > makes >> > the following concrete changes to the synapse architecture >> > >> > Synapse can no longer be deployed just as a pure module in axis2, it >> > requires much more work. >> > The message mediation is restricted to HTTP and HTTPS, which I am not >> > sure >> > whether we want to keep it as it is. >> > >> > But still this new logic even doesn't address the original problem in >> > the >> > discussion. In the new logic transport listeners starts even before the >> > mediators getting loaded into synapse. >> > >> > I think we need to improve this, and to me Eric's point is completely a >> > valid point. I will further look into resolving this and will keep the >> > list >> > posted. >> > >> > Thanks, >> > Ruwan >> > >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva >> > wrote: >> >> >> >> Hi Indika, >> >> >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara >> >> wrote: >> >>> >> >>> If the synapse is run top on axis2 or any other, it should be properly >> >>> initialized and started before initialize synapse. >> >> >> >> >> >> We are talking about two things here. Initialization and startup. I >> >> agree >> >> synapse should inilialize after axis2. Also Synapse should start after >> >> Axis2. But at the moment it seems that Synapse is starting even before >> >> it >> >> initializes. The way Synapse is written it is perfectly normal to >> >> assume >> >> that it is started when Axis2 is started. But if we do it in the >> >> current >> >> way, this assumption is broken and can lead to failures as Eric said. >> >> If >> >> Axis2 is initialize properly we can initialize Synapse. As Eric said if >> >> both >> >> are successfully initialized we can start Axis2 transports, which >> >> automatically starts Synapse. >> >> >> >> Thanks, >> >> Supun. >> >> >> >> >> >>> >> >>> It is a well known >> >>> semantic that system should be in consistent state before use it. You >> >>> can refer [1] and it says why I did. >> >> >> >> >> >> >> >> >> >>> >> >>> The way message get in to synapse and mediation engine (main behavior) >> >>> are two different aspects and definitely should have two different >> >>> decision designs as it is wrong if main behavior depend on other >> >>> behavior. The starting, shutdown --- simply state (consistent) >> >>> management of mediation should not depend any thing. Axis2 Hander is >> >>> make way to get message into in to synapse and for good design, >> >>> mediation engine should separate from this design decision. Managing >> >>> mediation engine should be independent from axis2 or any other. >> >>> >> >>> If it is needed to avoid effect of started listeners if the synapse >> >>> mediation engine started up is failed, then only applicable >> >>> transaction semantic is compensation transaction. In order to enforce >> >>> that, it is needed to properly shutdown listeners, etc --- some how >> >>> need to move into a consistent state before system startup. >> >>> >> >>> [1] http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html >> >>> >> >>> Thanks >> >>> Indika >> >>> >> >>> - >> >>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> >>> For additional commands, e-mail: dev-h...@synapse.apache.org >> >>> >> >> >> >> >> >> >> >> -- >> >> Software Engineer, WSO2 Inc >> >> http://wso2.org >> >> supunk.blogspot.com >> >> >> >> >> > >> > >> > >> > -- >> > Ruwan Linton >> > Senior Software Engineer & Product Manager; WSO2 ESB; >> > http://wso2.org/esb >> > WSO2 Inc.; http://wso2.org >> > email: ru...@wso2.com; cell: +94 77 341 3097 >> > blog: http://ruwansblog.blogspot.com >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> > > > > -- > Ruwa
Re: VFS Text Files with spaces don't work.
Are you sure that these spaces get trimmed inside the VFS transport and not somewhere in your mediation? Normally the plain text message builder is designed to strictly preserve the file content (including spaces), so this would be a serious bug. Andreas On Thu, Apr 2, 2009 at 08:52, kimhorn wrote: > > Run into a problem with VFS reading text files with fixed field length > fields, where empty fields are padded with spaces. There are a number of B2B > formats that do this. > > If the empty fields are at the start or end of the file then when these are > inserted into XML as Payload the > XML removes the spaces. The text should be wrapped in CDATA with double > Quotes to preserve this space data; but VFS does not do this. So the fields > at start or end of file get lost and hence the whole file is now garbage. > > Hopefully reading them as binary files (not plan text) will get over this ? > Other ideas ? > > > -- > View this message in context: > http://www.nabble.com/VFS-Text-Files-with-spaces-don%27t-work.-tp22841970p22841970.html > Sent from the Synapse - Dev mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
