RE: [VOTE] Release Synapse-2.0.0 (Take2)
Hi Ruwan, Thanks for fixing the issues. Meanwhile I tested the updated migration template definition from the 2.0 branch and it worked without problems. Sorry, I completely forgot to create an issue for the minor indentation problem. Once you go through the API changes, some of my earlier mails to this list might be of help. While you are at it, it would be nice if you could also check my question regarding the visibility of the createSpecificMediator method. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Wednesday, December 15, 2010 3:03 PM To: dev@synapse.apache.org Subject: Re: [VOTE] Release Synapse-2.0.0 (Take2) Hi Eric, Fixed the httpcore version on the 2.0 branch and removed the patch from the 2.0 branch too. Also the migration tool has been fixed to copy the namespace declarations when migrating the configuration. Thanks, Ruwan On Sun, Dec 12, 2010 at 8:02 AM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: Hi Eric, On Sat, Dec 11, 2010 at 9:40 PM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: I found another issue with the nhttp transports: I guess Synapse 2.0 release should not be shipped with http core / http core nio 4.1 alpha 1 dependencies, but the final release version 4.1. I also think the patch for httpcore-193 is no longer needed and the binary patch should not be in the patches directory. Cool, I guess a good catch, will fix it. Apart from that I finished the mediator migration and I’m now starting to test including custom mediators. Unfortunately I will have to continue tomorrow, as I have to take care of other things today. Sure no problem. Regards, Eric PS: Is there already an updated version of the migration tool to test? Unfortunately not yet Eric, I didn't have time to work on that, planning to work on resolving all the issue today starting from now on. :-) Will post the tool once there is an update. Thanks, Ruwan From: Ruwan Linton [mailto:ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com] Sent: Thursday, December 09, 2010 11:08 AM To: dev@synapse.apache.orgmailto:dev@synapse.apache.org Subject: Re: [VOTE] Release Synapse-2.0.0 (Take2) Hiranya, I've fixed this dependency issue, I expect you to do a build on the local machine and check this, will wait for your comments to the next RC :-) Thanks, Ruwan On Thu, Dec 9, 2010 at 12:44 AM, Hiranya Jayathilaka hiranya...@gmail.commailto:hiranya...@gmail.com wrote: I hate to be a PITA but I see another issue with this. The FIX transport has been included in the latest binary. So that's good. But I can see that Quickfix/J has also crept into the distro (about 9MB). FIX transport also requires MINA and SLF4J which are not included in the binary. So IMO either we should include all the required dependencies or none of them. I think we should add an exclusion to Quickfix/J and keep it out of the binary. WDYT? Thanks, Hiranya On Wed, Dec 8, 2010 at 12:27 PM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: Hi Devs, This is take 2 call for votes to release Synapse-2.0.0. Please review the signed artifacts: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/artifacts/ The m2 repository is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/m2_repo/ Site update for this release is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/site/ SVN Info: revision is 1043322 on https://svn.apache.org/repos/asf/synapse/branches/2.0 Here's my +1 to declaring the above dist as Synapse-2.0.0. Thanks, Ruwan PS: The KEYS file for signing these releases http://www.apache.org/dist/synapse/KEYS -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.commailto:hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.orgmailto:dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.orgmailto:dev-h...@synapse.apache.org -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http
RE: [VOTE] Release Synapse-2.0.0 (Take2)
+1 to also do this before a final release! From: indika kumara [mailto:indika.k...@gmail.com] Sent: Sunday, December 12, 2010 6:34 PM To: dev@synapse.apache.org Subject: Re: [VOTE] Release Synapse-2.0.0 (Take2) Hi Devs, There is a statement in the '/java/org/apache/synapse/securevault/SecretResolver.java' which I had added for testing but forgot to remove. Statement : log.infohttp://log.info(Secret : + encryptedPassword + PlainText : + plainText); Shall I remove it ? Thanks, Indika
RE: [VOTE] Release Synapse-2.0.0 (Take2)
I found another issue with the nhttp transports: I guess Synapse 2.0 release should not be shipped with http core / http core nio 4.1 alpha 1 dependencies, but the final release version 4.1. I also think the patch for httpcore-193 is no longer needed and the binary patch should not be in the patches directory. Apart from that I finished the mediator migration and I’m now starting to test including custom mediators. Unfortunately I will have to continue tomorrow, as I have to take care of other things today. Regards, Eric PS: Is there already an updated version of the migration tool to test? From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Thursday, December 09, 2010 11:08 AM To: dev@synapse.apache.org Subject: Re: [VOTE] Release Synapse-2.0.0 (Take2) Hiranya, I've fixed this dependency issue, I expect you to do a build on the local machine and check this, will wait for your comments to the next RC :-) Thanks, Ruwan On Thu, Dec 9, 2010 at 12:44 AM, Hiranya Jayathilaka hiranya...@gmail.commailto:hiranya...@gmail.com wrote: I hate to be a PITA but I see another issue with this. The FIX transport has been included in the latest binary. So that's good. But I can see that Quickfix/J has also crept into the distro (about 9MB). FIX transport also requires MINA and SLF4J which are not included in the binary. So IMO either we should include all the required dependencies or none of them. I think we should add an exclusion to Quickfix/J and keep it out of the binary. WDYT? Thanks, Hiranya On Wed, Dec 8, 2010 at 12:27 PM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: Hi Devs, This is take 2 call for votes to release Synapse-2.0.0. Please review the signed artifacts: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/artifacts/ The m2 repository is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/m2_repo/ Site update for this release is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/site/ SVN Info: revision is 1043322 on https://svn.apache.org/repos/asf/synapse/branches/2.0 Here's my +1 to declaring the above dist as Synapse-2.0.0. Thanks, Ruwan PS: The KEYS file for signing these releases http://www.apache.org/dist/synapse/KEYS -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.commailto:hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.orgmailto:dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.orgmailto:dev-h...@synapse.apache.org -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
RE: [VOTE] Release Synapse-2.0.0 (Take2)
Hi all, here are my first test observations – let’s state it like that. So far I think it is best to simply bring them up to the list, so we can sort out which of those are to be considered expected behaviour and are somewhere documented and which are issues which should be fixed according to their priority (which also needs to be determined). 1) Synapse startup test with custom 1.2 config - config has been put into repository/conf/synapse-config as it seems to got ignored in repository/conf - Synapse does not startup due to a problem in the config (e.g. missing registry implementation class on the classpath) - Unexpected behaviour: Although Synapse detects the problems, tries to perform a clean shutdown, it “keeps hanging” and does not return to the shell with an error return value 2) Migration Tool - executing the migration tool expects a config in repository/conf (former config location) - old copy copied there and restarted - migration tool modifies config - Unexpected behaviour: - after migration config stays in repository/conf and needs to be manually copied to repository/conf/synapse-conf to be recognized - migration tool mistakenly removes namespaces (destroying the config), e.g. code xmlns:tns=http://www.w3.org/2003/05/soap-envelope; value=tns:Receiver/ -- syn:code value=tns:Receiver / resulting in startup issues - migration tool removes indentation at the beginning of each xml element 3) Traditional config in single file versus multi file configuration - Unexpected behaviour: - replacing dummy synapse.xml with old (converted) config is not enough, it results in errors if main and/or fault sequences are used (as the must exist only once), sequence files need to be removed from subdirectories 4) Usage of custom mediators / Site Documentation “Upgrading” - In the docu I could not quickly locate a document summarizing the steps which need to be done to upgrade custom mediators according to API changes (I received some AbstractMethodError). I did not check the mediator sources against the current libraries to find out what is no longer compiling…. Anyway a quick summary of API changes would be nice. As long as I haven’t check the points which do not compile I cannot say for sure, whether those problems are due to the fact that public methods not considered to be part of the public API have been used on our end (which is not unlikely at all). Once I find the time, I will move on with my tests (probably this late evening, CET)… Hope the feedback is still of help… Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Thursday, December 09, 2010 7:04 AM To: dev@synapse.apache.org Subject: Re: [VOTE] Release Synapse-2.0.0 (Take2) So the Sandesha module can be easily removed if you are not doing any reliable messaging stuff. Just need to delete the file from the repository/modules directory. I would even remove this error message from the custom build of Sandesha2 as we any way seem to go for the 3rd round of voting. :-) Eric, I would like to wait for your feedback to do the 3rd RC. So take your time, but report us any critical issue as soon as you get to them. May not need to be the complete list, you can report them one by one as and when you find those, so that we can fix them if needs to be and be ready for your next round of the feedback. BTW: must say that we really appreciate your feedback. Thanks, Ruwan
RE: [VOTE] Release Synapse-2.0.0 (Take2)
Ruwan, could you please have a glance on the source distribution folders modules/commons, modules/securevault. What is the purpose of the m2 repo folders “m2-repo-synapse-2.0.0”? This looks somehow strange. Additionally each maven root contains a pom.xml.orig. Thanks, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Wednesday, December 08, 2010 7:57 AM To: dev@synapse.apache.org Subject: [VOTE] Release Synapse-2.0.0 (Take2) Hi Devs, This is take 2 call for votes to release Synapse-2.0.0. Please review the signed artifacts: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/artifacts/ http://people.apache.org/~ruwan/synapse/2.0.0/artifacts/ The m2 repository is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/m2_repo/ Site update for this release is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/site/ SVN Info: revision is 1043322 on https://svn.apache.org/repos/asf/synapse/branches/2.0 Here's my +1 to declaring the above dist as Synapse-2.0.0. Thanks, Ruwan PS: The KEYS file for signing these releases http://www.apache.org/dist/synapse/KEYS -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
RE: [VOTE] Release Synapse-2.0.0 (Take2)
I tried to build from the RC2 source zip under Windows with Maven 2.0.9, but receive the following error message: Downloading: http://dist.wso2.org/maven2//org/apache/sandesha2/sandesha2-core/1.3-1041287/sandesha2-core-1.3-1041287.jar 370K downloaded [WARNING] *** CHECKSUM FAILED - Error retrieving checksum file for org/apache/sandesha2/sandesha2-core/1.3-1041287/sandesha2-core-1.3-1041287.jar - IGNORING … [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure error: error reading D:\projects\m2-repo\org\apache\sandesha2\sandesha2-core\1.3-1041287\sandesha2-core-1.3-1041287.jar; error in opening zip file I verified the file to be in my local repo. I’m also able to extract the file with jar –xvf without problems… It should not be a big issue that the library in the WSO2 repo has been deployed without a checksum file, or? With my settings Maven simply ignores this fact (although it is obviously not nice). But what is the issue with this archive? As I have never run into such an issue before has someone an idea how to quickly resolve this? Am I the only person having this issue? Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Wednesday, December 08, 2010 7:57 AM To: dev@synapse.apache.org Subject: [VOTE] Release Synapse-2.0.0 (Take2) Hi Devs, This is take 2 call for votes to release Synapse-2.0.0. Please review the signed artifacts: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/artifacts/ http://people.apache.org/~ruwan/synapse/2.0.0/artifacts/ The m2 repository is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/m2_repo/ Site update for this release is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/site/ SVN Info: revision is 1043322 on https://svn.apache.org/repos/asf/synapse/branches/2.0 Here's my +1 to declaring the above dist as Synapse-2.0.0. Thanks, Ruwan PS: The KEYS file for signing these releases http://www.apache.org/dist/synapse/KEYS -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
RE: [VOTE] Release Synapse-2.0.0 (Take2)
I found quite a bit of time to have a more detailed look at the incompatible changes and start with an upgrade process - comments inline. From: Hubert, Eric [mailto:eric.hub...@foxmobile.com] Sent: Thursday, December 09, 2010 12:40 PM To: dev@synapse.apache.org Subject: RE: [VOTE] Release Synapse-2.0.0 (Take2) Here is a list of incompatibilities immediately found. Some are only from unit tests - not all will be considered as public API. To solve some tasks access was needed for different reasons... Somehow sorted by importance: The type XYZ must implement the inherited abstract method AbstractMediatorFactory.createSpecificMediator(OMElement, Properties) The type XYZ must implement the inherited abstract method SynapseArtifact.getDescription() The type XYZ must implement the inherited abstract method SynapseArtifact.setDescription(String) Cannot override the final method from AbstractMediatorSerializer The field AbstractMediatorFactory.log is not visible The method createMediator(OMElement, Properties) in the type AbstractMediatorFactory is not applicable for the arguments (OMElement) The method createMediator(OMElement, Properties) in the type MediatorFactory is not applicable for the arguments (OMElement) The method createMediator(OMElement) of type XYZ must override or implement a supertype method All of the above is what I assume could/should be considered public API and all of the changes required to make custom mediator code compile again are trivial and quickly done. I did this for a couple of mediators. I have still one question: What has been the reason to add the Properties to the createSpecificMediator method in the AbstractMediatorFactory? I tried to answer this question myself and looked for usage of the properties in the source. I only checked a couple of implementation, but could nowhere find a use. Everywhere this parameter was ignored in the Factory implementations and callers passed in an empty Properties-Map. The method getMediator(OMElement, Properties) in the type MediatorFactoryFinder is not applicable for the arguments (OMElement) The method getMediator(OMElement, Properties) in the type MediatorFactoryFinder is not applicable for the arguments (OMElement) The method getInstance() is undefined for the type ServerManager DataSourceInformation cannot be resolved DataSourceRegistrar cannot be resolved JNDIBasedDataSourceRegistry cannot be resolved MiscellaneousUtil cannot be resolved RMIRegistryController The import org.apache.synapse.util.datasource The import org.apache.synapse.util.MiscellaneousUtil The import org.apache.synapse.util.RMIRegistryController All the above seems to be stuff which had never been designed for external usage. It should not be hard to figure out how to properly replace it. All but one compile errors are from test/mock code used for verification of correctness of mediator implementations (including factories/serializers). If you guys are not in hurry tomorrow I would like to: - fix the remaining issues in our custom code - use a fixed version of the migration tool to migrate a large configuration file (for my initial test I used something really small) - do some runtime mediation tests Unfortunately I will not find time today. Regards, Eric From: Hubert, Eric [mailto:eric.hub...@foxmobile.com] Sent: Thursday, December 09, 2010 11:44 AM To: dev@synapse.apache.org Subject: RE: [VOTE] Release Synapse-2.0.0 (Take2) Answers inline. Not every statement was meant to describe a problem, I simply always described what I did and what happened. Unexpected behaviour is separately mentioned... 1) Synapse startup test with custom 1.2 config - config has been put into repository/conf/synapse-config as it seems to got ignored in repository/conf I think this is by design and we need to document this on the Upgrading guide. Agreed. - Synapse does not startup due to a problem in the config (e.g. missing registry implementation class on the classpath) I will have a look at this, I guess this needs to be fixed if there is an issue, can you please give me a small config bit to re-produce this issue? may be you are using a WSO2 ESB registry class shipped with WSO2 which of course is not available in synapse. :-( Yes, my aim was to test a failure case. So it was absolutely expected that this fails. No issue at all! - Unexpected behaviour: Although Synapse detects the problems, tries to perform a clean shutdown, it keeps hanging and does not return to the shell with an error return value Can you please attach the log for this and steps to re-produce, this again I would like to fix depending on the complexity of the issue... and if this gets slipped from 2.0.0 I suggest immediately spinning a 2.0.1 to fix this and any other this sort of issues from the 2.0.0 branch. WDYT? Yes, I personally do not consider
RE: [VOTE] Release Synapse-2.0.0 (Take2)
Unfortunately I will also have to throw in a couple of issues. So far I'm still collecting them... Not sure when I will have reached the end as I'm currently somehow in a process of finding a problem, resolving it, moving on, finding next problem, resolving it... Hope to break out of this loop soon and find some time tomorrow to post a summary upon which you can decide whether those issues shall hold up the release process or be fixed afterwards. Of course I need to mention that I'm not starting from scratch, but rather test the migration path... Sorry, but I'm not yet ready to post something concrete, except for one obvious and non critical observation. I find it quite strange that a stock installation starts up with a log message on ERROR level: ERROR SandeshaModule Could not load module policies. Using default values. To me this reads more like a warning... Regards, Eric -Original Message- From: Hiranya Jayathilaka [mailto:hiranya...@gmail.com] Sent: Wednesday, December 08, 2010 8:14 PM To: dev@synapse.apache.org Subject: Re: [VOTE] Release Synapse-2.0.0 (Take2) I hate to be a PITA but I see another issue with this. The FIX transport has been included in the latest binary. So that's good. But I can see that Quickfix/J has also crept into the distro (about 9MB). FIX transport also requires MINA and SLF4J which are not included in the binary. So IMO either we should include all the required dependencies or none of them. I think we should add an exclusion to Quickfix/J and keep it out of the binary. WDYT? Thanks, Hiranya On Wed, Dec 8, 2010 at 12:27 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Hi Devs, This is take 2 call for votes to release Synapse-2.0.0. Please review the signed artifacts: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/artifacts/ The m2 repository is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/m2_repo/ Site update for this release is available at: http://people.apache.org/~ruwan/synapse/2.0.0-RC2/site/ SVN Info: revision is 1043322 on https://svn.apache.org/repos/asf/synapse/branches/2.0 Here's my +1 to declaring the above dist as Synapse-2.0.0. Thanks, Ruwan PS: The KEYS file for signing these releases http://www.apache.org/dist/synapse/KEYS -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: [VOTE] Release Synapse-2.0.0 (Take2)
Sorry, but I'm not yet ready to post something concrete, except for one obvious and non critical observation. I find it quite strange that a stock installation starts up with a log message on ERROR level: ERROR SandeshaModule Could not load module policies. Using default values. Well this is very much a Sandesha problem. But since we are on a custom Sandesha branch we might be able to fix this. Should the custom build of the Sandesha module be used by default at all or is this some optional functionality a user should configure, if he needs it? Regards, Eric
RE: [VOTE] Release Synapse 2.0.0
Great news Ruwan! I’ll see to give the binary a quick test tomorrow and will also have a cursory look at the maven site. Thanks, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Tuesday, December 07, 2010 6:38 PM To: dev@synapse.apache.org Subject: [VOTE] Release Synapse 2.0.0 Hi Devs, This is a call for votes to release much awaited Synapse-2.0.0. Please review the signed artifacts: http://people.apache.org/~ruwan/synapse/2.0.0/artifacts/ http://people.apache.org/~ruwan/synapse/2.0.0/artifacts/ The m2 repository is available at: http://people.apache.org/~ruwan/synapse/2.0.0/m2_repo/ Site update for this release is available at: http://people.apache.org/~ruwan/synapse/2.0.0/site/ SVN Info: revision is 1042972 on https://svn.apache.org/repos/asf/synapse/branches/2.0 Here's my +1 to declaring the above dist as Synapse-2.0.0. Thanks, Ruwan PS: The KEYS file for signing these releases http://www.apache.org/dist/synapse/KEYS -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
RE: Synapse configuration namespace
Well, I think I have to agree with Sanjiva’s statement about the meaning of namespaces for an end user. I also do not know many people really caring about namespaces as long as those namespaces are not causing any troubles. Maybe one should not look at a namespace change independent of other changes. If for whatever reason a configuration format and/or syntax has changed resulting in the possibility that some or even all the user’s configurations will no longer work with a newer software version and users receive a migration tool to convert their configurations using the old format into a new format, users also do not care whether there is a namespace change or not (as long as the migration tool works properly). API changes breaking existing custom extensions (in the case of Synapse primarily “mediators”) or (even more critical) changed runtime behaviour should normally affect end users much more. During the too long time without any release since the last release of Synapse in June 2008 (so about two and a half years ago) I’m pretty sure any of the above will be the case. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Sunday, November 21, 2010 3:25 PM To: dev@synapse.apache.org Cc: u...@synapse.apache.org Subject: Re: Synapse configuration namespace I'm +1 for a namespace change if we have changed the semantics of the synapse configuration language at a broader level. But since we haven't done any major change to the configuration language im 0 on this. So my opinion solely depend on what users will think and how they will get affected. Thanks, Supun.. On Sun, Nov 21, 2010 at 7:35 AM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: I found more incompatible changes :-( https://issues.apache.org/jira/browse/SYNAPSE-693?focusedCommentId=12934217page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12934217 I do not understand why you are opposing to changing the namespace with 2.0 release, while we have this sort of dangerous incompatibilities. Ruwan On Sun, Nov 21, 2010 at 6:43 AM, Sanjiva Weerawarana sanj...@opensource.lkmailto:sanj...@opensource.lk wrote: On Sat, Nov 20, 2010 at 8:58 PM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: Also, in general using namespaces to version XML schemas is generally considered bad practice. I don't think we are doing a versioning of the synapse configuration schema with the namespace, anyway most of Then what are you achieving with the namespace name change? the other schemas, like (WSDL, XSLT) have different namespaces for different versions. :-( Not correct .. WSDL 1.1 to 2.0 does do but in that case the languages and semantics are majorly different. The 2.0 language was also delivered by a whole different group instead of a small private club. XSLT was intentionally, carefully designed for forwards compatibility and has a version attribute: http://www.w3.org/TR/xslt#forwards http://www.w3.org/TR/xslt#forwardsThis was a James Clark masterpiece. Now see XSLT 2.0's section on backwards compatibility: http://www.w3.org/TR/xslt20/#backwards http://www.w3.org/TR/xslt20/#backwards Also there is more than the domain name or being a new TLP out from WS for this namespace change, which is, that Synapse is more than web services and it can handle many things apart from web services, as you know web services is just one connector among many other connectors for mediation, and that is why I do not want to limit the namespace to the ws.apache.orghttp://ws.apache.org. Yes Synapse is much more than Web services. However, IMO, most users don't bother to give any quality time to looking at the namespace and making judgments based on that. I'm done pushing my position on this topic :). Sanjiva. -- Sanjiva Weerawarana, Ph.D. Founder, Director Chief Scientist; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman CEO; WSO2; http://wso2.com/ Founder Director; Thinkcube Systems; http://www.thinkcube.com/ Member; Apache Software Foundation; http://www.apache.org/ Member; Sahana Software Foundation; http://www.sahanafoundation.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton -- Technical Lead, WSO2 Inc http://wso2.org supunk.blogspot.comhttp://supunk.blogspot.com
RE: Continuum as the Continuous Integration Solution
I’m also too late for this discussion but just wanted to let you know about my consent. I completely agree with Andreas. I know both CI solutions and Hudson is superior in many areas. To some degree the content of the build (error) messages can be customized in the job configuration “Editable Email Notification”. Build errors caused by the underlying infrastructure will happen with any build system. By the way, Hudson also incorporates support for many nice code quality plugins visualizing the history/trend of those results. In a separate “doc” job you can for example integrate java doc creation, findbugs, pmd, checkstyle, cobertura, etc – which can also add a lot of value to a project with limited extra configuration effort. I haven’t seen much usage of this in the Apache Hudson installation though. Maybe because many of the Apache projects have been already integrated in http://nemo.sonarsource.org/ with some rule set? Synapse is also present there. Regards, Eric +1 for Hudson. Thanks, Ruwan On Sat, Nov 13, 2010 at 4:21 PM, Andreas Veithen andreas.veit...@gmail.commailto:andreas.veit...@gmail.com wrote: On Fri, Nov 12, 2010 at 19:00, Hiranya Jayathilaka hiranya...@gmail.commailto:hiranya...@gmail.com wrote: On Fri, Nov 12, 2010 at 4:37 PM, Oleg Kalnichevski ol...@apache.orgmailto:ol...@apache.org wrote: On Fri, 2010-11-12 at 07:31 +0530, Hiranya Jayathilaka wrote: Thanks for your input. My concern is that Hudson reports/notifications sometimes are completely useless. Also recently there have been so many false negatives reported on the list. I was hoping that may be Continuum doesn't suffer these limitations. Thanks, Hiranya We at HttpComponents use both Continuum and Hudson, though, I personally find Hudson to be easier to manager and generally better. Both systems tend to produce false positives when running low on resources or are under heavy load. However in most cases the failures manifested themselves as various timeouts (connect / response timeouts) rather any particular flaw in the CI system. The main source of trouble with Hudson for me were frequent failures with deploying snapshots to the repository.apache.orghttp://repository.apache.org, which, as Andreas pointed out, has nothing to do with Hudson as such. I see. Thanks Andreas and Oleg for the details. I guess we'll be sticking with Hudson :) You're welcome. Note that if you have questions about why a particular build has failed or if you would like to improve the configuration of the Synapse jobs, please feel free to ask. BTW: there will be false negatives because repository.apache.orghttp://repository.apache.org again has problems :-(
RE: Next release of Apache Synapse?
Hi Chris! Except for known issues with the Bean Scripting Framework (which had been incorporated with JSR-223 in Java 6) and the script mediator I don’t think you should have issues with Synapse 1.2 and Java 6 in general. So if this is your only concern I wouldn’t consider this as a blocker. If you need to you can also workaround the above mentioned issue. Modifying a start script if necessary should also be a quite easy task. Did you face any other specific issues with Synapse 1.2 and Java 6? Regards, Eric From: Gibson, Chris C. (MSFC-IS60)[UNITeS] [mailto:chris.gib...@nasa.gov] Sent: Monday, May 24, 2010 4:46 PM To: dev@synapse.apache.org Subject: RE: Next release of Apache Synapse? Ruwan, Thank you for your reply. We are currently using Synapse 1.2, but we are in the process of moving our application to a customer compliant environment (JDK 1.6/Tomcat6/64-bit OS). The sooner that we can get a version that works with JDK 1.6 the better. Thanks, Chris From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, May 23, 2010 10:07 AM To: dev@synapse.apache.org Subject: Re: Next release of Apache Synapse? Hi Gibson, We are looking at a time line of like a month from here on wards. If you are planning to use synapse, what sort of a time line are you looking at? Thanks, Ruwan On Sat, May 22, 2010 at 4:57 PM, Heshan Suriyaarachchi heshan.suriyaarach...@gmail.commailto:heshan.suriyaarach...@gmail.com wrote: Apache Synapse will be released after the next releases of Apache Axiom and Apache Axis2. On Fri, May 21, 2010 at 8:00 PM, Gibson, Chris C. (MSFC-IS60)[UNITeS] chris.gib...@nasa.govmailto:chris.gib...@nasa.gov wrote: When will the next release of Apache Synapse be? -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/ -- Ruwan Linton Software Architect Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
RE: Synapse 2.0 ??
Hi Ruwan, I have a set of new stuff in mind to be completed on the 2.0 release as well. So if there is no objection I would like to bring in a release plan to be executed with the set of features that we are going to do for the 2.0 release of Synapse. WDYT? No objections – only thoughts… Why not just dropping the current 1.3-branch and recreating from trunk to stabilize there? From a project perspective I think it is important to release more frequently. I’m not quite sure whether the new features really justify a major release. I would see this differently, if we had done any incompatible changes or completely modified the configuration language for example… Also if we now incorporate even more features, the release, however we are going to call it, will take even longer until it can get out. Regards, Eric
RE: Making the Synapse configuration language XML Schema compliant
Hi Ruwan, Since we are planning to go for a 2.0 release of Synapse directly, I am planning to make some changes to the Synapse Configuration Language which will make it XML Schema compliant and is planing to write a XML Schema for the Synapse Configuration Language. +1 This sounds like a very good idea and I would consider this to be really a major change, definitely justifying a 2.0 release. We will make sure to give proper migration tool to migrate 1.x configurations into 2.x Thoughts? Won’t this take a rather long time to realize and test? I’m still thinking about the option to release a 1.3 rather shortly before moving on to larger changes. Regards, Eric
RE: JMX notifications for Endpoint state changes
Hi, I 100% agree with Ruwan, that a global configuration shall not address individual services, endpoints or sequences. This would make the configuration extremely hard to read and understand. I think of this more in an object oriented fashion as properties of the elements inheriting defaults from their parents. Anyway I think I already stated my idea. I’m not against the idea of defining named policies/aspects and reference them on any level, but at the moment, I do not see the big value. It would make perfectly sense, if such a configuration would consist of many sub configuration elements we would like to share across multiple configuration elements. For a single boolean or even a set of booleans, this might not make it easier to understand without adding any extra value. Anyway I can’t imagine a useful referenced bundling of individual aspects. Maybe I got something wrong with your last idea Ruwan, but wouldn’t the user end up with some fancy named aspect configurations like this ALL-OFF, ALL-ON, ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION, STATISTIC_AND_NOTIFICATION and thousands of other potentially useful combinations just to reuse the combination of Booleans? This doesn’t sound like being of help. Indika proposed a policy definitions per aspect type to externalize, if I got it right. This would make sense for me at the moment a policy could contain more elements than just the Boolean, e.g. a certain further filtering – on, but only for some defined events. In order to not have to redefine those filters all over the place, one could reference a policy definition. Could make perfectly sense and would be very open for more complex aspect configurations. Too me the concept of inheritance from global definitions across the different levels would help most to reduce the configuration amount. And this is independent from using simple attributes with on/off or complex referenced policies. So maybe all ideas can be integrated into a good solution? Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Saturday, December 05, 2009 3:44 AM To: dev@synapse.apache.org Subject: Re: JMX notifications for Endpoint state changes Hhhmmm, not sure whether it is good to keep a one global aspect configuration which configures all the child nodes even when you need to turn on statistics (for example) for a given sequence, that will make the configuration readability harder. I would think of the implementation when deciding the configuration design, so that it is not affecting the performance as well. I would like to keep a global configuration of aspects, yes as Supun explined that can define whether all services, all endpoints or sequences but not a named entity. The default behaviour will be at global level all these will be turned off for all types of entities. Then at each and every element level you can define there aspects using the same configuraiton. Alternately, we could let the aspect configurations to be refered from from all the elements, inorder to make this work we need to be able to define a named set of aspects and from services and sequences they can refer to its aspect. It will enable us to reuse the aspect configuraitons of the same type within different elements without redefining. Being said all that I would like to do the initial implementation of this, considering the amount of change that this idea is going to take us. Thanks, Ruwan On Sat, Dec 5, 2009 at 2:04 AM, Supun Kamburugamuva supu...@gmail.commailto:supu...@gmail.com wrote: Hi, If we can define the statistics enabled endpoints or mediators at the top level aspect configuration we can leave the aspect configuration element only to the top level. This reduce the clutter from the specific component configurations. Specific component configurations can focus only on what they are mean to do. Things like statistics collection can be separated from the mediator configurations. Thanks, Supun.. On Sat, Dec 5, 2009 at 1:56 AM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: I would vote for both, on global and on those child elements where it is applicable with the simple rule, that at runtime the most specific one wins. This would allow for the following scenarios. Turn it off for all (globally) Turn it off globally, but only activate it on demand for specific endpoints, services etc. Turn it on globally Turn it on globally, but disable it for some specific services, endpoints (exclusions) Of cause you could also add a configuration right in the middle on the level of the services or endpoints etc., if someone also wants to turn an aspect only on for ALL services, but not for all endpoints, but just some of them. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.commailto:supu...@gmail.com] Sent: Friday, December 04, 2009 8:15 PM To: dev
RE: JMX notifications for Endpoint state changes
Please see my comments inline! I agree with you, but we can keep that for future, if we are going to have complex policies as aspect configurations that you do not want to duplicate within the entries. Anyway I can’t imagine a useful referenced bundling of individual aspects. Maybe I got something wrong with your last idea Ruwan, but wouldn’t the user end up with some fancy named aspect configurations like this ALL-OFF, ALL-ON, ONLY_STATISTIC, ONLY_TRACING, ONLY_NOTIFICATION, STATISTIC_AND_NOTIFICATION and thousands of other potentially useful combinations just to reuse the combination of Booleans? This doesn’t sound like being of help. So here what I meant is not defining a set of named aspect configurations Rather the aspect configuration at the root level can be used to globally turn on that for all services but not endpoints, or all endpoints but not for sequences and so on. Ah, OK – now I understand what you meant. Why I think this is important is lets say you have a state in your production server where you do not exactly know which sequence is receiving the malformed messages (you do not yet know which sequence) but you do not want to clutter the trace log with all traces, and this option will allow you to turn on tracing for all the sequences without enabling tracing for other entries like endpoints and so on... If this feature was not there the only option that you had is to put the aspect configuration into each and every sequence in your configuration. Yes, this is an option although I don’t think it would be the only option. Another option would be to allow the aspects block on any level: global (under definitions), global for all services or sequences or endpoints (wherever it makes sense) and on each individual service, or sequence or endpoint. The global default could be overridden wherever you like. So for your example globally everything is turned off, but only on the sequences level the tracing is activated. This means it is only active for all sequences, until you decide to exclude some sequences explicitly on the particular sequence. Maybe you option is easier to understand, but not that flexible and definitely not the only option. If you would like to trace all but 10 out of 100 sequences, you would need to activate it on 90 sequences. With the above approach you would activate it at the global sequence level and only deactivate it on those 10 sequences you want to exclude. Lets get started with the existing boolean values and keep the space to include policies later on, because we do not have a concrete requirement to support policies right now, we might not do it correctly and it is better to address that when the need arises. :-) +1
RE: Advice on choosing http core NIO version for Synapse 1.2
Oleg, thanks for your clarifications!
If the reactor shutdown was requested in an orderly fashion there is a
pretty good chance it will shut down cleanly and there will be nothing
to look at the audit log. The audit log usually comes handy when the
reactor shuts down due to an unexpected fatal error.
Hmmm, how can one know the difference?
HttpCore does not do logging by itself.
Ah, I think this perfectly explains it.
I do not know Synapse that well to answer this question.
Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the
thrown IOReactorException including the cause information as early as it has a
chance to do so:
Thread t = new Thread(new Runnable() {
public void run() {
try {
ioReactor.execute(ioEventDispatch);
} catch (InterruptedIOException ex) {
log.fatal(Reactor Interrupted);
} catch (IOException e) {
log.fatal(Encountered an I/O error: + e.getMessage(), e);
}
}
}, HttpCoreNIOSender);
So before this pops up, AbstractMultiworkerIOReactor performs the IOReactor
shutdown in it's finally block, which obviously may take a while.
This should explain the behaviour I observed.
Was in this case the java.nio.channels.ClosedChannelException the cause
of the IOReactor shutdown?
Yes, it was.
Thanks for confirming this.
Was it correct to terminate the Reactor?
No, it was not. ClosedChannelException should not be considered fatal.
This was also my understanding.
It is a shame the exception is unchecked, though.
Agreed.
If some code within the core nio library decides to throw an
IOReactorException could it make sense to log the cause immediately or are
there cases where the code at higher levels may still consider it
otherwise.
IOReactorException is considered fatal and should be propagated to the
I/O reactor thread unless discarded by the IOReactorExceptionHandler
Ok, I now much better understand the expected flow. I was simply not aware,
that http core nio is not logging at all and delegates this to the client using
the library. This has some consequences to the order in which one can expect
error messages. Good to know.
Anyway, if I'm not wrong and all of the above makes at least partially
sense, than it looks to me that the fix in
http://issues.apache.org/jira/browse/HTTPCORE-169
which went in beta-3 should have prevented the IOReactor restart.
Correct. This is basically the same bug.
Thanks, Oleg you helped me a lot with your explanations. This is also just
another proof that it is a good idea for us to update to 4.0.1.
Thanks,
Eric
RE: Advice on choosing http core NIO version for Synapse 1.2
Hi Oleg, Eric Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the thrown IOReactorException including the cause information as early as it has a chance to do so: Eric - you are looking at a previous version of the code, when we enabled auto-restart on unexpected shutdown, we improved this logic. However the real cause is the ClosedChannelException issue. We can neatly log fatal causes when such a restart is performed, so that we will know in future, what caused such a filure Asankha, I actually was also a bit confused as I expected to find the code which attempts the restart. But if I’m not wrong I was really looking at trunk. Is it possible, that the change has only been applied to the Synapse 1.3 branch and not yet forward ported to the trunk? Lets work on getting this fix into HttpComponents, probably as you switch to the new HttpCore version, since this is a quite common scenario you encounter in your deployment Which fix are you referring to regarding HttpCompoents? Do you mean the one regarding the ClosedChannelException? This one has already been fixed for beta-3 and will be fine in 4.0.1. What other fix do you see which can be applied to HttpComponents directly? Sorry, maybe I’m a bit to tired this morning… Thanks, Eric
RE: Advice on choosing http core NIO version for Synapse 1.2
Asankha, I think found the related issue: https://issues.apache.org/jira/browse/SYNAPSE-600 According to your comment the fix has only been applied to the 1.3 branch. Is there any reason to not (yet) apply this change to the trunk? From: Hubert, Eric [mailto:eric.hub...@foxmobile.com] Sent: Monday, December 07, 2009 7:44 AM To: dev@synapse.apache.org Subject: RE: Advice on choosing http core NIO version for Synapse 1.2 Hi Oleg, Eric Me neither, but from what I've seen, in HttpCoreNIOSender Synapse logs the thrown IOReactorException including the cause information as early as it has a chance to do so: Eric - you are looking at a previous version of the code, when we enabled auto-restart on unexpected shutdown, we improved this logic. However the real cause is the ClosedChannelException issue. We can neatly log fatal causes when such a restart is performed, so that we will know in future, what caused such a filure Asankha, I actually was also a bit confused as I expected to find the code which attempts the restart. But if I’m not wrong I was really looking at trunk. Is it possible, that the change has only been applied to the Synapse 1.3 branch and not yet forward ported to the trunk? Lets work on getting this fix into HttpComponents, probably as you switch to the new HttpCore version, since this is a quite common scenario you encounter in your deployment Which fix are you referring to regarding HttpCompoents? Do you mean the one regarding the ClosedChannelException? This one has already been fixed for beta-3 and will be fine in 4.0.1. What other fix do you see which can be applied to HttpComponents directly? Sorry, maybe I’m a bit to tired this morning… Thanks, Eric
RE: JMX notifications for Endpoint state changes
Well, actually I thought in the same direction as Ruwan. If introducing a global configuration option it should be consistent with the other configurations like tracing and statistics. This was one point against adding this only for any newly introduced feature like JMX notifications. If we would like to use such a configuration option, than we should consistently support this also for statistics and tracing. Hi Ruwan, I think if we do this the correct way, the way you've suggested is the correct way. I was bit reluctant to do that because it is kind of like a big change. At least at the conceptual level. I like your idea and I'll come up with an implementation. Eric, What do you think?
RE: JMX notifications for Endpoint state changes
From: indika kumara [mailto:indika.k...@gmail.com] Sent: Friday, December 04, 2009 9:37 AM aspect statistics statistics policy /statistics trace trace policy / trace monitoring monitoring policy / monitoring reporting reporting policy /reporting …… /aspect To me a grouping makes absolutely sense. This would also be beneficial to have at the global level below definitions. I don't think that adding more and more aspects directly on the top level would be a good option. So yes, I like this idea... Regards, Eric
RE: JMX notifications for Endpoint state changes
I would vote for both, on global and on those child elements where it is applicable with the simple rule, that at runtime the most specific one wins. This would allow for the following scenarios. Turn it off for all (globally) Turn it off globally, but only activate it on demand for specific endpoints, services etc. Turn it on globally Turn it on globally, but disable it for some specific services, endpoints (exclusions) Of cause you could also add a configuration right in the middle on the level of the services or endpoints etc., if someone also wants to turn an aspect only on for ALL services, but not for all endpoints, but just some of them. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Friday, December 04, 2009 8:15 PM To: dev@synapse.apache.org Subject: Re: JMX notifications for Endpoint state changes +1 from me as well to the new aspect configuration. This solves the problem more cleanly. I'm not clear about one thing. Shall we make this aspect configuration to be a child of other elements like mediators and endpoints or is it a top level configuration only? Thanks, Supun.. On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton ruwan.lin...@gmail.commailto:ruwan.lin...@gmail.com wrote: +1, we should go for this, and I think it will be very useful in a production set up; if anything goes wrong and the admin wants to enable tracing for the full synapse config he do not have to go onto each and every config bit. OTOH, if he knows where the issue is he can just enable tracing of that proxy only. Thnaks, Ruwan On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: Well, actually I thought in the same direction as Ruwan. If introducing a global configuration option it should be consistent with the other configurations like tracing and statistics. This was one point against adding this only for any newly introduced feature like JMX notifications. If we would like to use such a configuration option, than we should consistently support this also for statistics and tracing. Hi Ruwan, I think if we do this the correct way, the way you've suggested is the correct way. I was bit reluctant to do that because it is kind of like a big change. At least at the conceptual level. I like your idea and I'll come up with an implementation. Eric, What do you think? -- Ruwan Linton Technical Lead Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.commailto:ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.comhttp://supunk.blogspot.com
RE: JMX notifications for Endpoint state changes
Hi Supun, I’m +1 on the idea in general. There are at least two things which come immediately into my mind we probably should consider when (before) implementing this feature: 1) Configuration concept for event creation 2) Notification Object Type to use 1) Here we should consider how configurable we want to keep the event creation. So I’m thinking on some decisions like this: - only turn on/off event creation per type (e.g. type endpoint marked as suspended) - or configurable per data object itself (e.g. on endpoint level) as part of the configuration language Here I also see a trade off. On the one hand the user will likely only be interested to keep his monitoring configuration in one central place. Definitely he may not be interested in all kind of events. Of course there is always the chance of using a NotificationFilter. 2) Depending on what information we want to distribute as part of an event object we should keep in mind that the client needs to have the Notification Object in his class path. So if using a non-standard object (e.g. a custom subclass of javax.management.Notification or non standard objects stored inside the notification or one of its standard subclasses) we should always keep this in mind and think about its implications and at least consider this in the artefact structure (created deployment units). Personally when working with JMX I always try to avoid non-standard objects and restrict myself to standard types if possible. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Wednesday, December 02, 2009 10:47 PM To: dev@synapse.apache.org Subject: JMX notifications for Endpoint state changes Hi, At the moment Synapse exposes endpoint statistics through JMX. In case of Endpoint state changes (i.e. marked as SUSPENDED) we can provide JMX notifications. This allows users to take actions promptly without waiting for pulling the endpoint status data. I would like to know the opinion of the community. The implementation is simple and if you agree on this I can provide a patch. Thanks, Supun.. -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.comhttp://supunk.blogspot.com
RE: JMX notifications for Endpoint state changes
Hi Supun, You are welcome! Regarding my second point I think you are still able to deliver some details, if you really like. If I remember correctly there are actually three attributes type, message and userData, type and message being String and type being Object. So you can still use userData to add more detail which should not go into the message. The only thing is that the type of the user data should be some standard Object and not some custom type. It has been a while since I last looked into this, but you may at least want to check this… Regarding my first point I assumed you would already have some user requirements in mind as most of the time this is the starting point… I’m not quite sure if all users really do need this capability at all, although I really see its value. So at least I would expect a switch to turn this feature completely on and off (also as part of an initial implementation). The decision about activating the feature by default, or having the user to activate it on demand – is of cause something different. What do others think about this? Any “more advanced” configuration could also follow later on – I agree. My idea was just a more practical one. Depending on how Synapse is operated it might be the case that some of the endpoints are somehow “expected” to be suspended from time to time whereas others are expected to be 100% stable. Normally monitoring configuration is handled in one central place. The configuration knows about what events shall generate an alert and which ones have to be ignored to don’t flood the operational guys with “false positives”. This could be realized by proper filtering. On the other hand generating lots of events useless events will impose some overhead which might be avoidable, if events are already fired selectively. This of cause only makes sense if the configuration is managed centrally along with the monitoring configurations. If this is done manually, most users will probably prefer to filter on the client (monitoring) side. Just my personal 0.2 cents from both a users and a developer’s perspective. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Thursday, December 03, 2009 7:08 PM To: dev@synapse.apache.org Subject: Re: JMX notifications for Endpoint state changes Hi Eric, Thanks for the suggestions. I like your second idea. In Endpoint case I think we can avoid using a User defined notification. We simply send a notification of type synapse.endpoint.state.change. We don't need to say what is the current state using a user defined notification. User can query the MBean and figure out what is the current state. My personal opinion about your first idea is we should consider it after the initial implementation depending on the user requirements. This gives us time to think about the correct way to have the configurations. Still I don't have a clear understanding about how to configure this. So my initial plan was to enable it for all the endpoints as in the normal JMX case. If we can come up with a correct sensible way to introduce this to the configuration, I'm +1 for implementing it. Thanks, Supun.. On Thu, Dec 3, 2009 at 1:32 PM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: Hi Supun, I’m +1 on the idea in general. There are at least two things which come immediately into my mind we probably should consider when (before) implementing this feature: 1) Configuration concept for event creation 2) Notification Object Type to use 1) Here we should consider how configurable we want to keep the event creation. So I’m thinking on some decisions like this: - only turn on/off event creation per type (e.g. type endpoint marked as suspended) - or configurable per data object itself (e.g. on endpoint level) as part of the configuration language Here I also see a trade off. On the one hand the user will likely only be interested to keep his monitoring configuration in one central place. Definitely he may not be interested in all kind of events. Of course there is always the chance of using a NotificationFilter. 2) Depending on what information we want to distribute as part of an event object we should keep in mind that the client needs to have the Notification Object in his class path. So if using a non-standard object (e.g. a custom subclass of javax.management.Notification or non standard objects stored inside the notification or one of its standard subclasses) we should always keep this in mind and think about its implications and at least consider this in the artefact structure (created deployment units). Personally when working with JMX I always try to avoid non-standard objects and restrict myself to standard types if possible. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmmailto:supu...@gmail.comhttp://ail.com] Sent
RE: JMX notifications for Endpoint state changes
Agreed, coupling statistics and notification would not be a good idea as we are talking about two non-related things. Regarding useful configurations options I would also need to think a bit more about it… Introducing an optional attribute on the endpoint level to turn the feature selectively on/off might (depending on the default) force the user having to set it on a large number of configuration items. Having a global switch (either on or off) plus the ability to override the global option on the endpoint level may save configuration overhead and turn out to be more flexible, but could also make the configuration harder to read/understand. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Thursday, December 03, 2009 9:17 PM To: dev@synapse.apache.org Subject: Re: JMX notifications for Endpoint state changes HI Eric, I can understand your suggestion about turning notifications on/off selectively. One thing is if the statistics are enabled for a endpoint then enable the notifications. But statistics and notifications are two different things. So that may be not good. Any ideas from the community how to do this? May be we can introduce an attribute to the endpoint configuration? Thanks, Supun.. On Fri, Dec 4, 2009 at 1:33 AM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: Hi Supun, You are welcome! Regarding my second point I think you are still able to deliver some details, if you really like. If I remember correctly there are actually three attributes type, message and userData, type and message being String and type being Object. So you can still use userData to add more detail which should not go into the message. The only thing is that the type of the user data should be some standard Object and not some custom type. It has been a while since I last looked into this, but you may at least want to check this… Regarding my first point I assumed you would already have some user requirements in mind as most of the time this is the starting point… I’m not quite sure if all users really do need this capability at all, although I really see its value. So at least I would expect a switch to turn this feature completely on and off (also as part of an initial implementation). The decision about activating the feature by default, or having the user to activate it on demand – is of cause something different. What do others think about this? Any “more advanced” configuration could also follow later on – I agree. My idea was just a more practical one. Depending on how Synapse is operated it might be the case that some of the endpoints are somehow “expected” to be suspended from time to time whereas others are expected to be 100% stable. Normally monitoring configuration is handled in one central place. The configuration knows about what events shall generate an alert and which ones have to be ignored to don’t flood the operational guys with “false positives”. This could be realized by proper filtering. On the other hand generating lots of events useless events will impose some overhead which might be avoidable, if events are already fired selectively. This of cause only makes sense if the configuration is managed centrally along with the monitoring configurations. If this is done manually, most users will probably prefer to filter on the client (monitoring) side. Just my personal 0.2 cents from both a users and a developer’s perspective. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.commailto:supu...@gmail.com] Sent: Thursday, December 03, 2009 7:08 PM To: dev@synapse.apache.orgmailto:dev@synapse.apache.org Subject: Re: JMX notifications for Endpoint state changes Hi Eric, Thanks for the suggestions. I like your second idea. In Endpoint case I think we can avoid using a User defined notification. We simply send a notification of type synapse.endpoint.state.change. We don't need to say what is the current state using a user defined notification. User can query the MBean and figure out what is the current state. My personal opinion about your first idea is we should consider it after the initial implementation depending on the user requirements. This gives us time to think about the correct way to have the configurations. Still I don't have a clear understanding about how to configure this. So my initial plan was to enable it for all the endpoints as in the normal JMX case. If we can come up with a correct sensible way to introduce this to the configuration, I'm +1 for implementing it. Thanks, Supun.. On Thu, Dec 3, 2009 at 1:32 PM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: Hi Supun, I’m +1 on the idea in general. There are at least two things which come immediately into my mind we probably should consider when (before) implementing this feature: 1) Configuration concept
RE: [VOTE] Supun Kamburugamuwa as a committer
+1 From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Folks, Supun has been contributing to the Apache Synapse for quite a while now, and has been contributed a lot of patches for synapse, including the documentation and configuration samples. Here's my vote: +1 for making Supun a committer for Synapse
RE: Binding nhttp transport to multiple network interfaces
Hi Supun, Asankha is referring to the parameter “bind-address of transportReceiver in axis2.xml. Please refer to http://people.apache.org/~veithen/synapse/transports.html#Transport_listener_parameters for more detail! Regards, Eric PS: Once again many thanks to Andreas for improving the docu on trunk! Can you please point me to the configuration for server side? Is it in the nhttp.properties file or axis2.xml?
RE: Binding nhttp transport to multiple network interfaces
Hi Supun, I think your understanding is correct and there is currently no way to address this requirement (if it is one). The ListeningIORector of HTTP Core NIO is used with one ListenerEndpoint. I guess one would need to extend HttpCoreNIOListener to support multiple ListenerEndpoints. Actually Oleg and Asankha should know much better. I have never thought about this… I think the Http Core NIO Lib, should be able to cope with this. Regards, Eric If I understood the configuration correctly it can bind to one interface/network address or all of them. Is there a way to bind to something like to 2 out of 4 interfaces?
RE: Constant/reproducable order of elements in synapse.xml
Hi Supun, Please see my comments inline! Synapse language is treated as a programming language at least for the out side world. For example sequences can be attributed to functions. In any programming language the order in which these symbols occur does not matter as long as the symbols can be found by the caller. Agreed. So I have doubts in implementing an order for the synapse elements. By order I meant something like all the sequences are at the top then the proxy services etc. I share these doubts, but you describe exactly the current implementation. Please have a look at: SynapseXMLConfigurationSerializer.serializeConfiguration(SynapseConfiguration synCfg). It uses a fixed order of top level elements. Specific element serializers are then using an order depending on the way the configuration has been stored in memory. Mostly the XML information will be transferred to strongly typed data structures. While deserializing those values, currently a fixed order will be used. This might be different, from the one originally read in. Some list like structures are stored to unordered Map-Implementations for faster key-value access. While deserializing those values you end up with a random order. I think that this part could be fixed rather easily by using LinkedHashMap preserving the key order in which entries have been added to the map. When a user types in the synapse.xml, we should be able to preserve the order in which they have entered the elements in the synapse.xml. If you meant this one I'm +1 for implementing it. I also agree this would be the most desirable option, although the current implementation seems to be very far a way from that. Each factory/serializer pair would need to be designed for this purpose (e.g. keep a list or list of linked maps or any suitable structure of read elements/attributes, store it for deserialization purposes only and use this to retrieve the values in the exact order from structured object structures). I guess only something like this could warrant a working round-trip serialization/deserialization where the user may modify any part of the configuration, insert new stuff at any allowed place and this exact order will be preserved during later deserializations. So my concrete suggestion for a start was just to replace all class member implementations of SynapseConfiguration which are currently of type HashMap with LinkedHashMap. From my point of view this is at least an improvement. No pain, big gain? ;-) Regards, Eric
RE: Constant/reproducable order of elements in synapse.xml
Hi Supun, If the object model does not preserve the order in which it has been created a serializer would need to store the order in some place independent from the configuration model itself which is also accessible by the deserializer at any later stage. Another implication is, that it is not enough to feed a deserializer just with the configuration model alone. It would need the additional meta data to be able to preserve the original order. Also any serializer/factory-deserializer-pair would need to implement this. Maybe others have already discussed about this at design time? Any input from the devs early involved? Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Monday, November 09, 2009 5:46 AM To: dev@synapse.apache.org Subject: Re: Constant/reproducable order of elements in synapse.xml Hi Eric, I thought about this a bit further. Synapse runs on an object model. Not on a XML configuration. As far as I understood this was the original goal. Also it makes sense. The synapse configuration can be created using XML or may be spring or may be pure programming. At the synapse object model layer I think it is logical to use a hash map. If a particular serialization and building wants to have an order it is the responsibility of the build and serialize method writer to impose it. Isn't there a way to impose this at the serialize and builder level? Thanks, Supun.. On Sun, Nov 8, 2009 at 2:22 AM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: Hi Supun, Please see my comments inline! Synapse language is treated as a programming language at least for the out side world. For example sequences can be attributed to functions. In any programming language the order in which these symbols occur does not matter as long as the symbols can be found by the caller. Agreed. So I have doubts in implementing an order for the synapse elements. By order I meant something like all the sequences are at the top then the proxy services etc. I share these doubts, but you describe exactly the current implementation. Please have a look at: SynapseXMLConfigurationSerializer.serializeConfiguration(SynapseConfiguration synCfg). It uses a fixed order of top level elements. Specific element serializers are then using an order depending on the way the configuration has been stored in memory. Mostly the XML information will be transferred to strongly typed data structures. While deserializing those values, currently a fixed order will be used. This might be different, from the one originally read in. Some list like structures are stored to unordered Map-Implementations for faster key-value access. While deserializing those values you end up with a random order. I think that this part could be fixed rather easily by using LinkedHashMap preserving the key order in which entries have been added to the map. When a user types in the synapse.xml, we should be able to preserve the order in which they have entered the elements in the synapse.xml. If you meant this one I'm +1 for implementing it. I also agree this would be the most desirable option, although the current implementation seems to be very far a way from that. Each factory/serializer pair would need to be designed for this purpose (e.g. keep a list or list of linked maps or any suitable structure of read elements/attributes, store it for deserialization purposes only and use this to retrieve the values in the exact order from structured object structures). I guess only something like this could warrant a working round-trip serialization/deserialization where the user may modify any part of the configuration, insert new stuff at any allowed place and this exact order will be preserved during later deserializations. So my concrete suggestion for a start was just to replace all class member implementations of SynapseConfiguration which are currently of type HashMap with LinkedHashMap. From my point of view this is at least an improvement. No pain, big gain? ;-) Regards, Eric -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.comhttp://supunk.blogspot.com
RE: Implementing Type Support for the Property Mediator
From: Hiranya Jayathilaka [mailto:hiranya...@gmail.com] To solve this problem I would like to propose adding a new attribute to the property mediator. The new attribute, named 'type' will allow specifying a type for the parameter value. The property mediator will make sure that the value is properly cast into the specified type before setting the value. If the attribute is not specified the default type 'string' will be used so the existing behavior won't be affected. If there are no objections, I would like to contribute this improvement to Synapse. So WDYT? Your comments and feedback are most appreciated.
RE: Implementing Type Support for the Property Mediator
From: Hiranya Jayathilaka [mailto:hiranya...@gmail.com] Currently the property mediator sets all property values as strings. But in certain cases we will want to set property values of other types (integers, floats, OMElement etc). To solve this problem I would like to propose adding a new attribute to the property mediator. The new attribute, named 'type' will allow specifying a type for the parameter value. The property mediator will make sure that the value is properly cast into the specified type before setting the value. If the attribute is not specified the default type 'string' will be used so the existing behavior won't be affected. If there are no objections, I would like to contribute this improvement to Synapse. So WDYT? Your comments and feedback are most appreciated. +1, sounds like a useful feature
RE: Design-Flaw in AbstractDBMediatorFactory and sub classes?
Hi all, I have created https://issues.apache.org/jira/browse/SYNAPSE-594 and attached a patch to move the logic to lookup/create data sources from the mediator creation to the init-phase of the db mediators. I did not find time to test the changes intensively. Anyway existing tests are passing… I tried to improve the existing code, although it is still not optimal. Regards, Eric From: Supun Kamburugamuva [mailto:supu...@gmail.com] Sent: Thursday, November 05, 2009 9:14 AM To: dev@synapse.apache.org Subject: Re: Design-Flaw in AbstractDBMediatorFactory and sub classes? +1, this makes sense. It would be really great if we could enforce this behavior as well. Supunn.. On Wed, Nov 4, 2009 at 1:52 PM, Hubert, Eric eric.hub...@foxmobile.commailto:eric.hub...@foxmobile.com wrote: Hi Synapse-Devs, While having a glance on the way Synapse creates its internal memory representation of the Synapse configuration I think I stumbled across a design flaw in the AbstractDBMediatorFactory and its sub classes. Please correct me, if I’m wrong on the following assumptions: - the process of building the in-memory object representation of the Synapse configuration has to be separated from the initialisation of mediators - it is not the responsibility of mediator factories to initialize mediators, but to create the mediator (object representation) of the mediator configuration as part of the Synapse configuration - this allows one to create a configuration model from a synapse configuration (e.g. stored in an XML file) without the need to have an initialized environment running - this separation is also manifested in different execution phases within the startup process: 1) create Synapse configuration 2) create Synapse environment 3) initialize Synapse configuration with Synapse environment (calls init() on all config elements supporting some kind of lifecycle) Unfortunately I noticed that my assumptions are wrong, although I honestly think they SHOULD be correct. It is currently not possible to create a Synapse Configuration from a synapse.xml which makes use of mediators which are created based on the AbstractDBMediatorFactory. The reason is, mediator creation and initialization are mixed and the factories take responsibility of both. During the creation defined datasources are build (including datasource lookup which can only work, if the DataSourceHelper has been initialized). I think the creation of the synapse configuration model itself should not depend on external dependencies. The initialization should rather be done in the init-Method of the AbstractDBMediator, instead of the create-method of the AbstractDBMediatorFactory. What do others think? Here is the current stacktrace, if someone tries to build a synapse configuration with standalone code like this: SynapseConfiguration synapseConfiguration = scb.getConfiguration(synapseConfigFileName); org.apache.synapse.commons.SynapseCommonsException: DataSourceHelper has not been initialized, it requires to be initialized at org.apache.synapse.commons.datasource.DataSourceHelper.assertInitialized(DataSourceHelper.java:108) at org.apache.synapse.commons.datasource.DataSourceHelper.getRepositoryBasedDataSourceFinder(DataSourceHelper.java:122) at org.apache.synapse.config.xml.AbstractDBMediatorFactory.lookupDataSource(AbstractDBMediatorFactory.java:145) at org.apache.synapse.config.xml.AbstractDBMediatorFactory.buildDataSource(AbstractDBMediatorFactory.java:121) ... Regards, Eric -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.comhttp://supunk.blogspot.com
RE: Synapse build failure???
Hi, Although I'm also not able to reproduce the test failure locally according to the information Andreas has provided it looks quite obvious what is happening. The Synapse test case assumes that if the original request misses information about the charset encoding to use this will not change on the way. Reading the RFC I'm not clear about the correct behaviour. But if I interpret http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.4.1 correctly, we might want to change the unit test to just check the content-type using startsWith() for the case the charset has not been set explicitly, although I'm not sure if it is the correct behaviour for Axiom to use a hardcoded default of utf-8 for the case a charset encoding is not present. Especially the reason given in the commit message Andreas refers to (preventing an NPE) does not sound to be the correct motivation. What do others thing? Regards, Eric Ruwan, It is not the HTTP transport that is failing on Hudson, it is a unit test in synapse-extensions, which is broken because of a change in Axiom done by someone from IBM; see SYNAPSE-590. Andreas On Sun, Oct 11, 2009 at 18:29, Ruwan Linton ruwan.lin...@gmail.com wrote: Oleg, the thing is I am also not seeing a test failure, but Hudson is blaming us :-) I was trying to reproduce the error... ScriptMediatorTests are failing to me because I am on JDK-1.6 but not nhttp transport. Not sure why that is failing on Hudson? :-(, I don't think your changes broke any test cases, since the failure on Hudson seems to be there even before that commit. Thanks, Ruwan
RE: Synapse build failure???
Isn't Hessian a binary protocol that should never have a charset? Yes, thinking about it - I think you are right. The content-type should always be only x-application/Hessian, no charset. Regards, Eric
RE: SLF4J dependency??
Hi Ruwan, I think we already had this topic in April. ;-) At that time we identified qpid and mina, if I'm not wrong. Mina was only used by Quickfix/J... But here a mail I pulled of my mail archive: - Mail from Ruwan Sa 04.04.2009 14:26 --- On Sat, Apr 4, 2009 at 5:44 PM, Andreas Veithen andreas.veit...@gmail.com wrote: On Sat, Apr 4, 2009 at 13:50, Ruwan Linton ruwan.lin...@gmail.com wrote: On Sat, Apr 4, 2009 at 4:28 PM, Hiranya Jayathilaka hiranya...@gmail.com wrote: I believe slf4j is required only for the FIX transport. It is a MINA dependency which is used by Quickfix/J. If it is not used by anything else we should remove this. Good point, Asankha, are we going to ship the QFJ jar files, I think we have decided to remove these and document this under the fix transport configuration for the user to put in these dependencies upon configuring it, right?? This JAR only takes 9 KB. I would just leave it in the distribution. The advantage is that whenever a user adds a library that uses the SLF4J framework, logging will correctly work out of the box without the need for the user to understand the relationship between log4j, SLF4J and commons-logging. I am completely OK with keeping this, but not QuickFixJ and other related dependencies, because FIX is a domain specific transport which wont be required for many users. Ruwan From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Friday, September 25, 2009 8:45 AM To: dev@synapse.apache.org Subject: SLF4J dependency?? Does any body know why we have slf4j libraries on the lib directory of the synapse distribution? That was the reason for the JDK1.5 failure of the build :-(, I just want to make sure there is no code using slf4j directly before getting rid of them :-)
RE: Synapse 1.3 - Ruwan Linton as the Release Manager
+1 We have been waiting to make the 1.3 release for sometime now.. but mainly due to the dependency project releases it is still pending. As I think Ruwan is in a better position to get these releases out in time, I am requesting him to take over the role of Release Manager for 1.3. Here is my +1 for him to get things rolling - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: [PROPOSAL] Hierarchical directory based configuration as the default configuration
Hi Ruwan, I’m also +1 on this one. I hope it will still be possible to move the whole synapse-config directory out of the directory structure to any place the user wants it to have like it is now possible for synapse.xml. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, August 10, 2009 7:47 AM To: dev@synapse.apache.org Subject: [PROPOSAL] Hierarchical directory based configuration as the default configuration Folks, yet another proposal :-) Shall we make the hierarchical directory based synapse configuration to be the default configuration mechanism? It will give Synapse many advantages while we can make it have no disadvantages by supporting a synapse.xml file inside the root of the configuration hierarchy. So what I am proposing is that we create the repository/conf/synapse-config/ directory by the build and treat that as the synapse configuration root which will have sup directories to hold individual artifacts like sequences, endpoints and so on. At the same time we should support a synapse.xml file to be embeded with multiple elements in the configuration root (in this case the direcotry synapse-config) supporting the existing behaviour. With this we can get rid of the registry.xml and the local-entries.xml files that we have on the configuration root and bring them into the synapse.xml itself. This would make the configuration nicely placed with different levels as well as supporting the flat file at the same time by default. WDYT?
RE: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server
Hi Ruwan, hope you have fully recovered. While reviewing my patch, please also notice my comment on SYNAPSE-538. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Friday, May 01, 2009 5:56 AM To: dev@synapse.apache.org Subject: Re: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server Hi Eric, I was having a serious flue and was unable to work at all. I will have a look and will take care of this. Thanks, Ruwan On Thu, Apr 30, 2009 at 11:42 AM, Hubert, Eric eric.hub...@foxmobile.com wrote: Ruwan, did you find time to review this patch? I’m a bit concerned the patch could get invalid due to other changes to some of the rather central classes and would need additional update effort. From: Hubert, Eric [mailto:eric.hub...@foxmobile.com] Sent: Monday, April 27, 2009 9:16 PM To: dev@synapse.apache.org Subject: RE: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server Hi all, Asankha, thanks for taking a high-level look on the patch. I would also feel much more comfortable if Ruwan could take an additional low-level look at the patch. ;-) I spent a couple of hours doing those changes spread of several days in which also other changes had been applied to the same classes, so I needed to update my working copy several times to catch up. I hope no change slipped through. I also did some method renaming and removed unnecessary indirections to make the code more readable. There is still room for improvements, but I wanted to get out the first chunk to not have to update too frequently due to parallel changes. Regards, Eric From: Asankha Perera [mailto:asankha.apa...@gmail.com] On Behalf Of Asankha C. Perera Sent: Monday, April 27, 2009 3:17 PM To: dev@synapse.apache.org Subject: Re: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server Hi Eric I submitted my patch in a new JIRA (https://issues.apache.org/jira/browse/SYNAPSE-537 https://issues.apache.org/jira/browse/SYNAPSE-537 ) as could not locate the existing issue. Maybe Asankha can help out. I hope someone finds time to review. Afterwards I will go through all the known issues on my list regarding the shutdown handling. Ruwan, if you can provide more details or stack trace I will be happily jump in and help once I find the time - next weekend at the latest. I've done a brief look at the changes, and they seem ok to me at a high level. I think Ruwan should ok this as well with the recent changes he has been doing on the stop/restart logic. thanks asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.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: [jira] Commented: (SYNAPSE-537) Possibility to put server in maintenance mode and reload synapse configuration via JMX
With few other changes I have committed the patch. I must say this is a great improvement and this also fixes the shutdown issue. Great to hear that. Ruwan, thanks for reviewing and applying this patch! What do you and others think about my suggestion of moving all the server related classes from the top level to a new sub package server. Here is my original comment from the JIRA: While working on this patch I thought about moving some of the classes in the synapse top level package to a new server subpackage. I actually did not perform this change to ease the review, but I still think it would be a good idea. So what about moving the following classes: Axis2SynapseController JmxAdapter ServerConfigurationInformation ServerConfigurationInformationFactory ServerContextInformation ServerManager ServerState ServerStateDetectionStrategy SynapseController SynapseControllerFactory SynapseServer to synapse.server and ServerManagerView ServerManagerViewMBean to synapse.server.mbean (maybe also renaming them to ServerManagerControl and ServerManagerControlMBean.
RE: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server
Ruwan, did you find time to review this patch? I’m a bit concerned the patch could get invalid due to other changes to some of the rather central classes and would need additional update effort. From: Hubert, Eric [mailto:eric.hub...@foxmobile.com] Sent: Monday, April 27, 2009 9:16 PM To: dev@synapse.apache.org Subject: RE: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server Hi all, Asankha, thanks for taking a high-level look on the patch. I would also feel much more comfortable if Ruwan could take an additional low-level look at the patch. ;-) I spent a couple of hours doing those changes spread of several days in which also other changes had been applied to the same classes, so I needed to update my working copy several times to catch up. I hope no change slipped through. I also did some method renaming and removed unnecessary indirections to make the code more readable. There is still room for improvements, but I wanted to get out the first chunk to not have to update too frequently due to parallel changes. Regards, Eric From: Asankha Perera [mailto:asankha.apa...@gmail.com] On Behalf Of Asankha C. Perera Sent: Monday, April 27, 2009 3:17 PM To: dev@synapse.apache.org Subject: Re: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server Hi Eric I submitted my patch in a new JIRA (https://issues.apache.org/jira/browse/SYNAPSE-537 https://issues.apache.org/jira/browse/SYNAPSE-537 ) as could not locate the existing issue. Maybe Asankha can help out. I hope someone finds time to review. Afterwards I will go through all the known issues on my list regarding the shutdown handling. Ruwan, if you can provide more details or stack trace I will be happily jump in and help once I find the time - next weekend at the latest. I've done a brief look at the changes, and they seem ok to me at a high level. I think Ruwan should ok this as well with the recent changes he has been doing on the stop/restart logic. thanks asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com
RE: HttpCoreNIOListener$1 - System may be unstable: IOReactor encountered a runtime exception : null
Hi all, I guess this boils down to how we deal with broken, partial, and even possibly malicious requests in the NIO transport.. I will fix the issue pointed to by Andreas and Murali ASAP as I consider this critical. I agree with you Asankha. Although we have different root causes for RuntimeExceptions during request handling, the final result is currently the same for all those cases. Yes, we return true since the later versions of HttpCore dump some information and try to continue in the face of RT exceptions. What I feel is that we need to enhance the NIO transport to be stable in the face of broken, partial and malicious requests so that RT exceptions will not be thrown in such cases, and we will drop the connection with a WARN Yes, this for sure. If something slips through we hope that the HttpCore is able to continue without problems? Are there known situations for this? Regards, Eric
RE: HttpCoreNIOListener$1 - System may be unstable: IOReactor encountered a runtime exception : null
Hi Andreas,
are you sure this is the same issue?
What I observe when testing your described scenario is a NPE in
ServerHandler#outputReady (ContentOutputBuffer outBuf as context attribute
synapse.response-source-buffer seems to be null.
Reason:
In DefaultNHttpServerConnection#consumeInput the HeadLine is parsed using
BasicLineParser which throws a parse exception Invalid request line:
bufferconent which is caught in AbstractMessageParser and wrapped inside a
ProtocolException reusing the message. This one is again caught in
DefaultNHttpServerConnection as a subclass of HttpException, resetting the
input and calling exception() on the NHttpServiceHandler (in our case
LoggingNHttpServiceHandler). We are now in Synapse land logging the error and
delegating to NHttpServiceHandler#exception (in our case ServerHandler).
We don't get a request line, thus defaulting to HTTP 1.0 and construct a BAD
Request response (400), calling #commitResponseHideExceptions.
We are writing the response LoggingNHttpServerIOTarget#produceOutput --
DefaultNHttpServerConnection#produceOutput -- LoggingNHttpServiceHandler
#outputReady -- ServerHandler#outputReady
int bytesWritten = outBuf.produceContent(encoder);
causes NPE, as outBuf is null.
This runtime exception is caught in BaseIOReactor#writable and delegated to the
registered exception handler (in our case an anonymous inner class of
HttpCoreNIOListener with the following implementation:
ioReactor.setExceptionHandler(new IOReactorExceptionHandler() {
public boolean handle(IOException ioException) {
log.warn(System may be unstable: IOReactor encountered a
checked exception :
+ ioException.getMessage(), ioException);
return true;
}
public boolean handle(RuntimeException runtimeException) {
log.warn(System may be unstable: IOReactor encountered a
runtime exception :
+ runtimeException.getMessage(), runtimeException);
return true;
}
});
I wondering a bit about the return value. Taken from the JavaDoc of the
interface IOReactorExceptionHandler#handle
True if it is safe to ignore the exception and continue execution of the I/O
reactor; if the I/O reactor must throw {...@link RuntimeException} and
terminate
Hmm, is it really safe to proceed here? We do not test any detail of the
RuntimeException. To me this looks wrong.
This puts us in an endless loop.
I guess Asankha should be in the best position to comment on this. I just
wanted to throw in my quick observations on this one.
Regards,
Eric
-Original Message-
From: Andreas Veithen [mailto:andreas.veit...@gmail.com]
Sent: Tuesday, April 28, 2009 8:51 PM
To: dev@synapse.apache.org
Subject: Re: HttpCoreNIOListener$1 - System may be unstable: IOReactor
encountered a runtime exception : null
The problem can easily be reproduced with a current snapshot build:
- Start Synapse
- Do a telnet localhost 8280
- Hit enter
Andreas
On Tue, Apr 28, 2009 at 19:53, Hubert, Eric eric.hub...@foxmobile.com
wrote:
Hi all,
Hmmm, I'm actually not sure, if the issue pointed out by Paul is really
the cause of the problem.
Too me it looks like the status line of an HTTP request is parsed by the
BasicLineParse which throws an exception complaining about an invalid
protocol version (consisting of protocol name, separator and major.minor).
According to the output read from the buffer, this string is:
HTTP\1.1
I'm not completely sure, but I guess the trailing space will be skipped,
but what about the separator \. Shouldn't this be /?
If the character followed by the protocol name (HTTP) is not / this
exception will be thrown. Any possibility / changes to \ at some
point?
Regards,
Eric
-Original Message-
From: Paul Fremantle [mailto:pzf...@gmail.com]
Sent: Tuesday, April 28, 2009 6:32 PM
To: dev@synapse.apache.org
Subject: Re: HttpCoreNIOListener$1 - System may be unstable: IOReactor
encountered a runtime exception : null
Murali
Its probably this:
https://issues.apache.org/jira/browse/SYNAPSE-341
Paul
On Tue, Apr 28, 2009 at 3:39 PM, cmurali chakravart...@sddc.army.mil
wrote:
I am seeing the following in my synapse log after which the server
becomes
non-responsive. I have no other go except to just restart synapse. Is
there
any fix for this?
Thanks,
Muralidaran Chakravarthy
INFO | jvm 1 | 2009/04/27 18:17:11 | [I/O dispatcher 3] DEBUG
LoggingNHttpServiceHandler - HTTP connection [/144.100.83.31:1095]:
GET
/?
HTTP/1.0
INFO | jvm 1 | 2009/04/27 18:17:11 | [I/O dispatcher 4] DEBUG
LoggingNHttpServiceHandler - HTTP connection [/144.100.83.31:1094]:
Connected
INFO | jvm 1 | 2009/04/27 18:17:11 | [I/O dispatcher 3] DEBUG
RE: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server
Hi all, Asankha, thanks for taking a high-level look on the patch. I would also feel much more comfortable if Ruwan could take an additional low-level look at the patch. ;-) I spent a couple of hours doing those changes spread of several days in which also other changes had been applied to the same classes, so I needed to update my working copy several times to catch up. I hope no change slipped through. I also did some method renaming and removed unnecessary indirections to make the code more readable. There is still room for improvements, but I wanted to get out the first chunk to not have to update too frequently due to parallel changes. Regards, Eric From: Asankha Perera [mailto:asankha.apa...@gmail.com] On Behalf Of Asankha C. Perera Sent: Monday, April 27, 2009 3:17 PM To: dev@synapse.apache.org Subject: Re: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server Hi Eric I submitted my patch in a new JIRA (https://issues.apache.org/jira/browse/SYNAPSE-537 https://issues.apache.org/jira/browse/SYNAPSE-537 ) as could not locate the existing issue. Maybe Asankha can help out. I hope someone finds time to review. Afterwards I will go through all the known issues on my list regarding the shutdown handling. Ruwan, if you can provide more details or stack trace I will be happily jump in and help once I find the time - next weekend at the latest. I've done a brief look at the changes, and they seem ok to me at a high level. I think Ruwan should ok this as well with the recent changes he has been doing on the stop/restart logic. thanks asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com
RE: Error while stoping the Synapse server
Hi all, I'll have a look at this and will fix it. From the stack it looks like the shutdown order is wrong. Unfortunately I'll be travelling today without having access to the net today, but tonight or tomorrow I'll submit a patch to correct this if no one beats me to it. Regards, Eric -Original Message- From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Saturday, April 25, 2009 6:28 AM To: dev@synapse.apache.org Subject: Error while stoping the Synapse server Devs, On the latest build I am seeing an error while trying to stop Synapse, by killing the process (CTRL+C) on Unix. Is this local to me? I do have some local changes but they have nothing to do with this I guess. :-( 2009-04-25 09:49:40,580 [-] [Thread-9] INFO SynapseServer Shutting down Apache Synapse... 2009-04-25 09:49:40,582 [-] [HttpCoreNIOListener] INFO HttpCoreNIOListener HTTPS Listener Shutdown 2009-04-25 09:49:40,583 [-] [Thread-9] INFO VFSTransportListener VFS Listener Shutdown 2009-04-25 09:49:40,583 [-] [HttpCoreNIOListener] INFO HttpCoreNIOListener HTTP Listener Shutdown 2009-04-25 09:49:40,584 [-] [Thread-9] INFO MailTransportListener MAILTO Listener Shutdown 2009-04-25 09:49:40,585 [-] [HttpCoreNIOSender] INFO HttpCoreNIOSender HTTPS Sender Shutdown 2009-04-25 09:49:40,586 [-] [HttpCoreNIOSender] INFO HttpCoreNIOSender HTTP Sender Shutdown 2009-04-25 09:49:40,586 [-] [Thread-9] INFO VFSTransportSender VFS Sender Shutdown 2009-04-25 09:49:40,587 [-] [Thread-9] INFO JMSSender JMS Sender Shutdown 2009-04-25 09:49:40,588 [-] [Thread-9] INFO RMIRegistryController Removing the RMI registry bound to port : 1099 2009-04-25 09:49:40,604 [-] [Thread-9] INFO JmxAdapter JMXConnectorServer stopping on service:jmx:rmi:///jndi/rmi://ruwan:1099/synapse 2009-04-25 09:49:40,761 [-] [Thread-9] ERROR JmxAdapter Error while stopping remote JMX connector java.io.IOException: Cannot bind to URL: javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table] at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnector Server.java:814) at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.jav a:572) at org.apache.synapse.JmxAdapter.stop(JmxAdapter.java:140) at org.apache.synapse.Axis2SynapseController.stopJmxAdapter(Axis2SynapseContr oller.java:583) at org.apache.synapse.Axis2SynapseController.destroy(Axis2SynapseController.j ava:143) at org.apache.synapse.ServerManager.doDestroy(ServerManager.java:252) at org.apache.synapse.ServerManager.destroy(ServerManager.java:117) at org.apache.synapse.SynapseServer$1.run(SynapseServer.java:88) Caused by: javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table] at com.sun.jndi.rmi.registry.RegistryContext.unbind(RegistryContext.java:156) at com.sun.jndi.toolkit.url.GenericURLContext.unbind(GenericURLContext.java:2 54) at javax.naming.InitialContext.unbind(InitialContext.java:375) at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.jav a:565) ... 6 more Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemot eCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343) at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source) at com.sun.jndi.rmi.registry.RegistryContext.unbind(RegistryContext.java:152) ... 9 more 2009-04-25 09:49:40,772 [-] [Thread-9] INFO SynapseServer Apache Synapse shutdown complete 2009-04-25 09:49:40,773 [-] [Thread-9] INFO SynapseServer Halting JVM Thanks, Ruwan -- 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
RE: [jira] Updated: (SYNAPSE-536) Error while stoping the Synapse server
Hi Ruwan, I submitted a patch which should fix this issue you reported. Fortunately I was not able to reproduce it locally. Could you please first apply this patch locally and test if it fixes the issue for you! By the way, which log4j configuration are we using if running the server from synapse.sh? There is one directly in the lib directory which does not seem to be used and one in the synapse-core.jar and likely others... There are still a couple of other issues in the startup/shutdown logic you will notice once you call stop and start from ServerManager. I'm working on those issues as well. Thanks, Eric [ https://issues.apache.org/jira/browse/SYNAPSE- 536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated SYNAPSE-536: Attachment: Shutdown.patch Error while stoping the Synapse server -- Key: SYNAPSE-536 URL: https://issues.apache.org/jira/browse/SYNAPSE-536 Project: Synapse Issue Type: Bug Components: Core Affects Versions: NIGHTLY Reporter: Eric Hubert Fix For: 1.3 Attachments: Shutdown.patch Originally reported by Ruwan and confirmed by Hiranya: On the latest build I am seeing an error while trying to stop Synapse, by killing the process (CTRL+C) on Unix. Is this local to me? I do have some local changes but they have nothing to do with this I guess. :-( 2009-04-25 09:49:40,580 [-] [Thread-9] INFO SynapseServer Shutting down Apache Synapse... 2009-04-25 09:49:40,582 [-] [HttpCoreNIOListener] INFO HttpCoreNIOListener HTTPS Listener Shutdown 2009-04-25 09:49:40,583 [-] [Thread-9] INFO VFSTransportListener VFS Listener Shutdown 2009-04-25 09:49:40,583 [-] [HttpCoreNIOListener] INFO HttpCoreNIOListener HTTP Listener Shutdown 2009-04-25 09:49:40,584 [-] [Thread-9] INFO MailTransportListener MAILTO Listener Shutdown 2009-04-25 09:49:40,585 [-] [HttpCoreNIOSender] INFO HttpCoreNIOSender HTTPS Sender Shutdown 2009-04-25 09:49:40,586 [-] [HttpCoreNIOSender] INFO HttpCoreNIOSender HTTP Sender Shutdown 2009-04-25 09:49:40,586 [-] [Thread-9] INFO VFSTransportSender VFS Sender Shutdown 2009-04-25 09:49:40,587 [-] [Thread-9] INFO JMSSender JMS Sender Shutdown 2009-04-25 09:49:40,588 [-] [Thread-9] INFO RMIRegistryController Removing the RMI registry bound to port : 1099 2009-04-25 09:49:40,604 [-] [Thread-9] INFO JmxAdapter JMXConnectorServer stopping on service:jmx:rmi:///jndi/rmi://ruwan:1099/synapse 2009-04-25 09:49:40,761 [-] [Thread-9] ERROR JmxAdapter Error while stopping remote JMX connector java.io.IOException: Cannot bind to URL: javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table] at javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnector Server.java:814) at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.jav a:572) at org.apache.synapse.JmxAdapter.stop(JmxAdapter.java:140) at org.apache.synapse.Axis2SynapseController.stopJmxAdapter(Axis2SynapseContr oller.java:583) at org.apache.synapse.Axis2SynapseController.destroy(Axis2SynapseController.j ava:143) at org.apache.synapse.ServerManager.doDestroy(ServerManager.java:252) at org.apache.synapse.ServerManager.destroy(ServerManager.java:117) at org.apache.synapse.SynapseServer$1.run(SynapseServer.java:88) Caused by: javax.naming.CommunicationException [Root exception is java.rmi.NoSuchObjectException: no such object in table] at com.sun.jndi.rmi.registry.RegistryContext.unbind(RegistryContext.java:156) at com.sun.jndi.toolkit.url.GenericURLContext.unbind(GenericURLContext.java:2 54) at javax.naming.InitialContext.unbind(InitialContext.java:375) at javax.management.remote.rmi.RMIConnectorServer.stop(RMIConnectorServer.jav a:565) ... 6 more Caused by: java.rmi.NoSuchObjectException: no such object in table at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemot eCall.java:247) at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:343) at sun.rmi.registry.RegistryImpl_Stub.unbind(Unknown Source) at com.sun.jndi.rmi.registry.RegistryContext.unbind(RegistryContext.java:152) ... 9 more 2009-04-25 09:49:40,772 [-] [Thread-9] INFO SynapseServer Apache Synapse shutdown complete 2009-04-25 09:49:40,773 [-] [Thread-9] INFO SynapseServer Halting JVM Unfortunately I'm not able to reproduce this issue in my environment although from looking at the code the obvious reason seems to be the RMI registry is shutdown before the JmxAdapter
RE: Result: [VOTE] Eric Hubert as a committer
Hi all, thanks a lot for the warm welcome and the trust. Regarding the ICLA I have to first pass some legal concerns with my employer. We are currently discussing the option of signing a CCLA. I'm afraid that this will take some time. I'll keep you updated on the progress. In the meantime I'll continue to spent the few free minutes on finishing a patch regarding graceful restart. So if the issue with ICLA or CCLA has been solved, I would prefer the ID ehubert. According to the ASF committer list this seems to be available. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Friday, April 24, 2009 10:14 AM To: dev@synapse.apache.org Subject: Re: Result: [VOTE] Eric Hubert as a committer Congratulations Eric.. hope to see your much valuable contributions soon. Thanks, Ruwan On Fri, Apr 24, 2009 at 12:53 PM, Asankha C. Perera asan...@apache.org wrote: +1s from Ruwan, Saminda, Hiranya, Andreas, Upul and Asankha I call the vote closed! Congratulations and welcome Eric! Please fill out and fax the ICLA found at http://www.apache.org/licenses/icla.pdf, and let me know your preferred ID for the Apache account. thanks 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 -- 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: Build failed in Hudson: Syna pse - Trunk » Apache Synapse - U tility classes #606
Hi all, I double-checked my patch in https://issues.apache.org/jira/browse/SYNAPSE-526 and it looks to be OK. So everything should be there as well. Maybe the new files did not get added from the local sendbox to which the patch was applied. Anyway I hope it will be easy to fix for one of the committers. Thanks, Eric -Original Message- From: Hubert, Eric [mailto:eric.hub...@foxmobile.com] Sent: Tuesday, April 21, 2009 9:11 AM To: dev@synapse.apache.org Subject: RE: Build failed in Hudson: Synapse - Trunk » Apache Synapse - Utility classes #606 Hi all, the broken build is related to the applied JMX/security patch. No matter what exactly went wrong, the following new classes (all new classes?) are simply missing: synapse-core: org.apache.synapse.JmxAdapter org.apache.synapse.security.enumeration.CipherOperationMode org.apache.synapse.security.enumeration.EncodingType org.apache.synapse.security.tool.EncondingHelper synapse-utils: org.apache.synapse.commons.util.secret.SecretConfigurationConstants org.apache.synapse.commons.util.secret.SecretInformation org.apache.synapse.commons.util.secret.SecretInformationFactory org.apache.synapse.commons.util.jmx.JmxConfigurationConstants org.apache.synapse.commons.util.jmx.JmxInformation; org.apache.synapse.commons.util.jmx.JmxFactory; org.apache.synapse.commons.util.jmx.JmxSecretAuthenticator; org.apache.synapse.commons.util.jmx.MBeanRegistrar org.apache.synapse.commons.util.jmx.MBeanRepository To be able to quickly fix this, I attached a newly created patch against the current trunk. As a backup I created a zip with the files I touched or created, which should include all the above as well. Sorry, I don't know what caused this. Maybe I uploaded a wrong patch file, need to check this... I hope someone can quickly fix this. Thanks, Eric -Original Message- From: Apache Hudson Server [mailto:hud...@hudson.zones.apache.org] Sent: Tuesday, April 21, 2009 8:04 AM To: dev@synapse.apache.org Subject: Build failed in Hudson: Synapse - Trunk » Apache Synapse - Utility classes #606 See http://hudson.zones.apache.org/hudson/job/Synapse%20- %20Trunk/org.apache.synapse$synapse-utils/606/ -- [INFO] - -- - [INFO] Building Apache Synapse - Utility classes [INFO]task-segment: [clean, install] [INFO] - -- - [INFO] [clean:clean] [INFO] Deleting directory http://hudson.zones.apache.org/hudson/job/Synapse%20- %20Trunk/org.apache.synapse$synapse-utils/ws/target [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] snapshot org.apache.axis2:axis2-transport-jms:1.0-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-transport-jms:1.0-SNAPSHOT: checking for updates from wso2-m2 7K downloaded [INFO] snapshot org.apache.axis2:axis2-transport:1.0-SNAPSHOT: checking for updates from apache-incubating [INFO] snapshot org.apache.axis2:axis2-transport:1.0-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-transport:1.0-SNAPSHOT: checking for updates from wso2-m2 15K downloaded [INFO] snapshot org.apache.axis2:axis2-transport-base:1.0-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-transport-base:1.0-SNAPSHOT: checking for updates from wso2-m2 6K downloaded [INFO] snapshot org.apache.axis2:axis2-kernel:1.5-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-kernel:1.5-SNAPSHOT: checking for updates from wso2-m2 [INFO] snapshot org.apache.axis2:axis2-parent:1.5-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-parent:1.5-SNAPSHOT: checking for updates from wso2-m2 [INFO] snapshot org.apache.axis2:axis2-transport-local:1.5-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-transport-local:1.5-SNAPSHOT: checking for updates from wso2-m2 [INFO] snapshot org.apache.axis2:axis2-transport-mail:1.0-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot org.apache.axis2:axis2-transport-mail:1.0-SNAPSHOT: checking for updates from wso2-m2 5K downloaded Downloading: http://repository.apache.org/snapshots/javax/mail/mail/1.4.2/mail- 1.4.2.pom Downloading: http://dist.wso2.org/maven2//javax/mail/mail/1.4.2/mail- 1.4.2.pom Downloading: http://people.apache.org/~asankha/repository/javax/mail/mail/1.4.2/mail- 1.4.2.pom Downloading: http://repo1.maven.org/maven2/javax/mail/mail/1.4.2/mail- 1.4.2.pom [INFO] snapshot org.apache.axis2:axis2-adb:1.5-SNAPSHOT: checking for updates from apache-snapshots [INFO] snapshot
RE: Endless recursion in FaultHandler.handleFault()
Hi Ruwan, no problem. I can confirm your fix is solving the issue I had. Looking at your change one may consider renaming the cloneOptions() in the MessageHelper(), or? Now it is neither a deep copy nor a complete flat copy, or? You simply skip cloning all the addressing options. I think this should be at least reflected in the JavaDoc, although it might be better to change the method name as well. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, April 20, 2009 7:25 AM To: dev@synapse.apache.org Subject: Re: Endless recursion in FaultHandler.handleFault() Eric I properly fixed this you may verify this, sorry for the trouble. Thanks, Ruwan On Sat, Apr 18, 2009 at 10:35 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Hi Andreas, thanks for quickly fixing this! I was working on a couple of small improvements and was very confused as this suddenly happened. I was not sure whether it was related to my changes or the svn up. ;-) Regards, Eric See SYNAPSE-525. Andreas -- 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: JMX and security improvements
Hi all, I went though this change before the weekend, and it looked ok - I was expecting feedback from Indika as this touches on the security / secret stuff brought in recently.. but lets not delay it anymore as this touches a few files, unless Ruwan / Andreas has any feedback not to commit. Yeah, it would be fine if the code could be committed any time soon. Indika lately already indicated that he will not be able to spend much time on Synapse in the near future, so I did not expect an immediate answer from him, although this of cause would be very valuable. Personally I would like to highlight that I feel responsible for my submissions. So if something should break because I may have missed a test case, I will of cause help to fix the issue quickly. My next contribution basing on this one is already on the way. Actually the implementation is done, but I need a few more hours for proper testing. Regards, Eric
RE: Endless recursion in FaultHandler.handleFault()
Hi all, I'm still facing an issue which looks like a recursion (not the same), if the endpoint url is a non existing one resulting in a connection refused. Here is my endpoint config: syn:endpoint name=servicename#1.0#lbgroupname#A1###myhost syn:address uri=some_non_existing_url statistics=false syn:timeout syn:duration12/syn:duration syn:actionfault/syn:action /syn:timeout syn:markForSuspension syn:retriesBeforeSuspend3/syn:retriesBeforeSuspend syn:retryDelay500/syn:retryDelay /syn:markForSuspension syn:suspendOnFailure syn:initialDuration100/syn:initialDuration syn:progressionFactor3/syn:progressionFactor syn:maximumDuration30/syn:maximumDuration /syn:suspendOnFailure /syn:address /syn:endpoint [...] [HttpClientWorker-7] WARN FaultHandler - ERROR_CODE : 101503 ERROR_MESSAGE : Connection refused or failed for : myhost:6003 [HttpClientWorker-7] DEBUG AxisService - Get operation for anonOutInOp [HttpClientWorker-7] DEBUG AxisService - Found axis operation: org.apache.synapse.core.axis2.dynamicaxisoperat...@2720f6 [HttpClientWorker-7] DEBUG ConfigurationContext - registerOperationContext (false): org.apache.axis2.context.operationcont...@16a9d0a with key: urn:uuid:EEC7CAA6BBD62D98F91240074657255 [HttpClientWorker-7] DEBUG SandeshaModule$1 - Unsetting USE_ASYNC_OPERATIONS and DISABLE_RESPONSE_ACK for unreliable message [HttpClientWorker-7] DEBUG SandeshaModule$1 - Entry: SandeshaModule::resolveTarget [HttpClientWorker-7] DEBUG SandeshaUtil - Entry: SandeshaUtil::isMessageUnreliable [HttpClientWorker-7] DEBUG SandeshaUtil - Exit: SandeshaUtil::isMessageUnreliable, false [HttpClientWorker-7] DEBUG SandeshaModule$1 - Exit: SandeshaModule::resolveTarget [HttpClientWorker-7] DEBUG ConfigurationContext - registerOperationContext (false): org.apache.axis2.context.operationcont...@16a9d0a with key: urn:uuid:EEC7CAA6BBD62D98F91240074657255 [HttpClientWorker-7] DEBUG ConfigurationContext - msgContext: [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] action: [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for Phase soapmonitorPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase soapmonitorPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for phase soapmonitorPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for Phase OperationOutPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase OperationOutPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for phase OperationOutPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for Phase RMPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase RMPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for phase RMPhase [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for Phase PolicyDetermination [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase PolicyDetermination [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for phase PolicyDetermination [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for Phase MessageOut [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase MessageOut [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking Handler 'AddressingOutHandler' in Phase 'MessageOut' [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for phase MessageOut [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for Phase Security [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase Security [HttpClientWorker-7] DEBUG Phase - [MessageContext: logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for phase Security [HttpClientWorker-7] DEBUG
RE: Registering the handlers programatically
If you look at the way synapse operates, even though it seems like a module of axis2 it is really not, it just uses the axis2 handler architecture to leverage the other axis2 features while getting the message dispatched into synapse. So I propose to drop the module and programaticaly register theses handler after properly initializing the Synapse environment. WDYT? +1 – I think your explanation gets to the heart of it.
RE: startup order - correct place to start transport listeners
I put my comments inline as well. Please see my comments inline; What I meant in my original proposal is exactly this, but without preStart I think preStart is equivalent to the init, but we need postStart or some other meaning full method to do post startup tasks. Yeah, at the moment I sent my mail out I also came across the same thought. Did you notice my follow-up mail on this? I think we could put all calls in a start() method which delegates to the specific sub routines in the appropriate order. Actually also the tasks are part of the start process. It’s only the fact they are started after the listeners as they require them to be started in advance. This may not be just the tasks but also some mediators which requires to fetch some data from outside going through the transport senders at the startup?? Can you give me an example here? It can’t be something which is done on mediate() as this can only happen once a message arrives, and thus transports are started. So you are talking about something which currently happens inside the init method, which requires the transports to be available. Hmmm, interesting… I have no use case in mind. Maybe other can help on this. Actually if this would be the case I would find it consistent to not only implement ManagedLifecylce but rather Startup and split the implementation in a init-Phase were one can only do initialisation stuff which does not require transports. And a start-Phase where one can do any kind of one-time operation on startup also requiring the transports. Of course this would break existing mediators currently doing such stuff. This is why I’m asking about examples and use cases. So if we add a new method to the ManagedLifecycle called start you could, support these post startup work in a general manner rather than treating tasks starting as a special case. True, implementation of mediators would need to be changed either the one or the other way. I just don’t see so many use cases for the start()-method, but I may be wrong. Also any mediator could decide to implement ManagedLifecycle or some more specific interface extended by the startup behaviour. Otherwise you would often leave this method without implementation. Ok, looking inside the Startup interface it only sounds to be generic but infact it seems to be just a synonym for task, or? So I could also life with a ManagedLifecycle interface extended by a new start() method keeping this method always empty for my use cases. Of course this has also an advantage for the user. Only one interface to care about. What are other’s opinions? How shall we go on? Ruwan, would you do those changes on your own. If you would need some support, I could do this today. Today I have some hours I could spend. Tomorrow and next week doesn’t look too good on my side. Otherwise I will proceed with my work on the JMX stuff to remove some open issues as of the comments in the JIRA (the integration shouldn’t be done before the startup/shutdown has been changed though, I will then sync and update my patch accordingly) and a small patch regarding log output in the http transports. Looks like either way I will find enough useful stuff to help with today. Regards, Eric
RE: Synapse dependencies for 1.3
Instead of moving the amqp transport to experimental, why not split the synapse-transport module and have a separate module for each transport? This would make dependency management much easier because it would be clear which dependency is used by which transport. Also when using Maven to create a custom Synapse package [1], one could simply select the required transports as dependencies and let Maven handle the transitive dependencies. +1, makes perfectly sense. [1] http://people.apache.org/~veithen/synapse/deployment.html#Using_Maven_to _b uild_a_custom_distribution Very good and valuable work Andreas. I had also a short glance on your transport's section. Thanks for taking the time! I'm sure a lot of users will be quite happy to see this. Regards, Eric - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Synapse dependencies for 1.3
Hi, I am completely OK with keeping this, but not QuickFixJ and other related dependencies, because FIX is a domain specific transport which wont be required for many users I share the same opinion as Ruwan. I remember we already had some discussions about this: http://www.nabble.com/Bundling-of-transports-with-the-distribution---wha t-should-be-the-default--td21432781.html Nevertheless it should be made easy for a user to add a transport which is not shipped by default. Proper documentation about adding should be a prerequisite for removing it. Regards, Eric
RE: Synapse dependencies for 1.3
Regarding the place to store such information I would prefer a very central place like the transports section on the project page on which Andreas is currently working. Samples are very helpful and documentation on samples is valuable, but honestly I think currently too much information is hidden in setup and sample guides and should be more prominent and easier to locate. From: Hiranya Jayathilaka [mailto:hiranya...@gmail.com] Sent: Saturday, April 04, 2009 3:41 PM To: dev@synapse.apache.org Subject: Re: Synapse dependencies for 1.3 +1 to removing domain specific transports like FIX and AMQP from the standard distribution along with their corresponding dependencies. However as Eric pointed out we need to properly document how to add them later. We already have some information in the samples setup guide. But I think we can add a bit more information to it and most importantly we should publish it in a way so that an interested user can easily locate it. Thanks, Hiranya On Sat, Apr 4, 2009 at 6:44 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Hi, I am completely OK with keeping this, but not QuickFixJ and other related dependencies, because FIX is a domain specific transport which wont be required for many users I share the same opinion as Ruwan. I remember we already had some discussions about this: http://www.nabble.com/Bundling-of-transports-with-the-distribution---wha t-should-be-the-default--td21432781.html Nevertheless it should be made easy for a user to add a transport which is not shipped by default. Proper documentation about adding should be a prerequisite for removing it. Regards, Eric
RE: Custom mediator with the snapshot build
The second option is to log a message by default if its sent to /soap/xxx on the console.. so that the user knows what went wrong.. Of course +1 for this. I agree.. lets just do this now... This sounds to be the best option. What is send back to the client in case the context does not match? I'd assume currently nothing?
RE: startup order - correct place to start transport listeners
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. I'd be + 1 to integrate this as a core functionality once Ruwan has finished his work on the startup and shutdown logic. I also share Indika's evaluation that this is a core functionality which should be closely integrated with the other start- and shutup logic. 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.
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: 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
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 eric.hub...@foxmobile.com 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: startup order - correct place to start transport listeners
Hi all, unfortunately at the moment I'm still not able to help much with this discussion as I did not spend enough time to understand the coupling of Axis2 and Synapse in detail. Generally what Indika writes about the decoupling of transports and mediation engine makes definitely sense from my high level view. The only point where I disagree is the startup of listeners. It seems impossible to me to compensate broken requests. In any system listeners should generally be the last to start and first to stop to avoid operating in an inconsistent state mostly combined with data loss and SLA violations. Besides a note from Ruwan that task initialisation depends on listeners being started before, I see no real reason to start the listeners that early. I first trial to move them to a later point showed no problems for me (also I did not test tasks). I definitely find it important to clarify the whole startup/shutdown logic including the Axis2 module aspect, where I can't provide any useful feedback, before releasing 1.3. Regards, Eric
startup order - correct place to start transport listeners
Hi all, while working on patch to make direct use of the existing MBeans in Synapse I was wondering about the current order of actions during Synapse startup. If I'm not wrong it looks like the transports are started somewhere in the middle of the Synapse startup. Is this observation correct? Is this on purpose? Too me this looks like a serious error. The listeners should be started only once the whole configuration process has been successfully finished. Otherwise traffic would be accepted even though the initialization of the configuration (proxies, sequences, endpoints and so on) may fail. Here is what I have read from the code (standalone deployment): 1 SynapseServer.main() 1.1 ServerConfigurationInformationFactory.createServerConfigurationInformation(args); 1.2 ServerManager.getInstance(); 1.3 ServerManager.init() 1.3.1 SynapseControllerFactory.createSynapseController(configurationInformation); 1.3.2 ServerManager.doInit() 1.3.2.1 Axis2SynapseController.init() 1.3.2.1.1 Axis2SynapseController.createNewInstance() 1.3.2.1.1.1 Axis2SynapseController.createConfigurationContextFromFileSystem() 1.3.2.1.2 create and Init Listener Manager 1.3.2.1.3 start transports --- this looks terribly wrong 1.3.2.2 Axis2SynapseController.initDefaults() 1.3.2.2.1 Axis2SynapseController.addDefaultBuildersAndFormatters(configurationContext.getAxisConfiguration()); 1.3.2.2.2 Axis2SynapseController.loadMediatorExtensions(); 1.3.2.2.3 Axis2SynapseController.setupDataSources(); 1.4 ServerManager.start() 1.4.1 ServerManager.assertInitialized() 1.4.2 ServerManager.doInit() 1.4.3 ServerManager.doStart() 1.4.3.1 Axis2SynapseController.createSynapseConfiguration(); 1.4.3.2 Axis2SynapseController.createSynapseEnvironment(); 1.4.3.2.1 Axis2SynapseController.setupSynapse() 1.4.3.2.1.1 Axis2SynapseController.addServerIPAndHostEnrties(); 1.4.3.2.1.2 Axis2SynapseController.setupMainMediation(); 1.4.3.2.1.3 Axis2SynapseController.setupProxyServiceMediation(); 1.4.3.2.1.4 Axis2SynapseController.setupEventSources(); 1.4.3.2.2 SynapseConfiguration.init() -- up to this point a lot of errors can occur resulting in Synapse startup failed Why don't we start listeners only if we reach this point without an error? I would propose to start the listeners immediately before the log output: ServerManager - Ready for processing Is there anything which will prevent this to work? If not I would be willing to work on a patch. So far I didn't test those hypotheses, so I may be wrong. Please feel to correct my current understanding! Regards, Eric
RE: [jira] Resolved: (SYNAPSE-521) Send Synapse generated Hessian faults with HTTP status 200
Hi, It seems like we have a Jira downtime so I answer directly on the list. Asankha C. Perera resolved SYNAPSE-521. --- Resolution: Fixed Assignee: Asankha C. Perera Thanks Eric for the fix. I just removed an unused constant HTTP_SC_OK from the NhttpConstants Asankha, thanks for reviewing and committing and sorry about forgetting to remove the now unused constant. This has been a remaining of the alternative solution using the FaultMediator to set the HTTP 200 status code. With the latest approach it was possible to use the int constants of HttpStatus directly. Regards, Eric
RE: SYNAPSE-357 Provide a switch to send mediator to specify whether to build the envelope before sending or not
My suggestions are: send property name=BUILD_ENVELOPE value=true/ ... other such properties.../ endpoint ./ /send +1 I thought exactly the same while reading the original mail. The short name with env could be quite confusing for new users which are not the deeply involved into the technical details. There is often an association Env -- Environment. I also think that the property approach fits well, especially if more properties will follow. OR/AND send endpoint property name=BUILD_ENVELOPE value=true/ ... other such properties.../ /endpoint /send I'm not that sure about this one due to missing use cases in mind. Asankha, could you give some examples? I wouldn't like this as an replacement of the above option (OR), but would also not be against it as an alternative (AND). Regards, Eric
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi all, sorry for the gap in response. I was actually very busy due to some platform live issues which needed my attention. Anyway I tried to finish up the discussed work on the handling of synapse generated faults send out as a Hessian message. Looking at the possibilities I discarded the approach setting the HTTP status code in the FaultMediator. Actually if it is already indicated from the HessianMessageBuilder that 200 shall be used for faults, then this information should be directly evaluated from the nhttp transport module. Everything else would just be a useless indirection introducing another transport coupling. So how do you like the new idea to evaluate this property directly inside NhttpCoreNIOSencer. Please have a look at my patch provided at: https://issues.apache.org/jira/browse/SYNAPSE-521 Feedback welcome! Indika, this should also address your concerns, or? Thanks for the feedback, Eric
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Yes, this has been exactly the direction I was looking for. I guess Asankha made just a typo in the name of the suggested property and wanted to use FAULTS_AS_HTTP200 as 500 would be the current default. Then the rest of the sentence setting it to true in the HessianMessageBuilder would still apply. ;-) If nobody objects or has better ideas, I'll go ahead and propose a patch following Asankha's suggestion. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, March 16, 2009 4:27 AM To: dev@synapse.apache.org Subject: Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter I think all last three suggestions will work nicely to solve this issue, but I think asankha's solution seems quite handy in this case as well as in most of the other POX cases (it is a generic solution). I think HessianBuilder should set the value to false in the asankha's suggestion, because hessian messages want them to be to 200 rather than 500. :-) Thanks, Ruwan On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera asan...@apache.org wrote: Hi all Yes, I think the overhead in the FaultMediator is rather low. It already handles a lot of other application protocol specific stuff. The only thing which is not nice is that the way to detect the Hessian message is making assumptions on the transport used (content-type of http transport header as a decision criteria). But there are obviously other alternatives to implement the isHessianMessage() method (e.g. letting the builder write an info about the application protocol used in a defined place within the message context or even something smarter?). Yes, there are limitations regarding message transformations changing the application protocol, this is true. On the other side this would be a relatively hard job. Either reimplementing the whole protocol or integrating a Hessian library (many library versions are incompatible amongst each other). Once we really do this, the effort to change a few lines in the FaultMediator can be neglected. Considering all that has been brought up in this thread and the above in particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' - and the Hessian builders would set this property to True. This way the fault mediator is not Hessian specific. When the fault mediator is invoked later, it would check this property and perform the logic given in Eric's patch. I believe many POX messages would also benefit from this - where many fault messages would actually go on the wire as HTTP 200's.. cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.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: Creating HessianFaults using FaultMediator/HessianMessageFormatter
For two reasons: 1. Message formatters should be protocol independent (even if they have access to the full MessageContext). This is currently not the case. Whereas the rest of Synapse is totally unaware of any Hessian specifics, the Hessian Builder/Formatter pair is actually the protocol dependent implementation. It is only used for Hessian Messages and has to be configured (activated) in axis2.xml for the specific content type. 2. Probably when the message formatter is invoked, it is already too late to set the HTTP status code. Excactly! Thats the definite reason. The whole http headers are already written when it comes to the formatter. See HttpCoreNIOSender.sendAsyncResponse(): worker.getServiceHandler().commitResponse(worker.getConn(), response); // ... OutputStream out = worker.getOutputStream(); //.. messageFormatter.writeTo(msgContext, format, out, false); Regards, Eric - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Just throwing an idea into the discussion: What about an Axis2 module?
Ideas are always welcome. Unfortunately I can nothing put into this discussion
as I'm currently not aware of the Axis2 design.
Is there any overview of the Axis2 design and what one can do within an Axis2
module? Hmmm, seems to be the wrong list to ask this, but actually Synapse is
currently very tightly coupled with Axis2.
I hope someone more knowledgeable can comment on this idea.
Regards,
Eric
Andreas
On Sun, Mar 15, 2009 at 00:11, Hubert, Eric eric.hub...@foxmobile.com
wrote:
I thought it might be useful for discussion to also have some sample
code to illustrate b).
Please find attached a quick implementation showing the idea.
Regards,
Eric
Hi all,
if someone wants to use the FaultMediator in conjunction with Hessian
messages he has to know that he to set the HTTP status code to 200,
after
using the FaultMediator and before using the SendMediator.
Normally (for SOAP messages) the HTTP status code is 500, but Ruwan
once
created a possibility to override this value using a property of scope
Axis2.
So declaratively this is possible in synapse.xml via adding the
following
configuration block:
syn:switch source=get-property('transport', 'Content-Type')
syn:case regex=x-application/hessian
syn:property name=HTTP_SC value=200 scope=axis2/
/syn:case
/syn:switch
The HessianFormatter transforms the SOAPFault to a Hessian fault and
writes a valid Hessian fault message to the client, which deserializes
the
fault message to a HessianServiceException with the proper message.
This only works if the HTTP status code is 200. Any other messages will
not be deserialized by the Hessian Client libraries.
I guess most people trying out the Hessian support would stumple over
this
issue. I see two possibilities and would like to here your opinion.
a) Document this behaviour and the needed configuration online.
b) Extend the FaultMediator to set this property programmatically
depending on the content-type header.
I see advantages and disadvantages with both approaches. Currently the
FaultMediator is already handling the differences between SOAP 1.1,
SOAP
1.2 and POX. This would need three of four more lines as well as the
duplication or a move of a content-type constant for x-
application/hessian as for sure a dependency from the core to the
extensions module must not exist.
Anyone having a clever option c in mind? Comments are welcome!
Regards,
Eric
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
1. Message formatters should be protocol independent (even if they have access to the full MessageContext). This is currently not the case. Whereas the rest of Synapse is totally unaware of any Hessian specifics, the Hessian Builder/Formatter pair is actually the protocol dependent implementation. It is only used for Hessian Messages and has to be configured (activated) in axis2.xml for the specific content type. My statement was not precise enough. What I wanted to say is that message formatters should be _transport_ protocol independent. On the other hand, as you point out, they implement a specific _application_ protocol. BTW, is Hessian used on other transport protocols, such as JMS? Ah, sorry that I didn't get your point at first. This makes sense. I haven't seen some other transport protocol than http for Hessian so far as it is RPC oriented, but it should be possible to use other transports. Regards, Eric
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Yes, I think the overhead in the FaultMediator is rather low. It already handles a lot of other application protocol specific stuff. The only thing which is not nice is that the way to detect the Hessian message is making assumptions on the transport used (content-type of http transport header as a decision criteria). But there are obviously other alternatives to implement the isHessianMessage() method (e.g. letting the builder write an info about the application protocol used in a defined place within the message context or even something smarter?). Yes, there are limitations regarding message transformations changing the application protocol, this is true. On the other side this would be a relatively hard job. Either reimplementing the whole protocol or integrating a Hessian library (many library versions are incompatible amongst each other). Once we really do this, the effort to change a few lines in the FaultMediator can be neglected. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, March 15, 2009 9:43 PM To: dev@synapse.apache.org Subject: Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter Hi all, Using the formatter to do this is impossible because at the time formatter is getting called the HTTP status code has already been written to the transport. I don't think we need an axis2 module to do this, it is just setting a property on the axis2 message context and we should not be adding another handler into the axis2 handler chain to do this. I would improve the Fault mediator to be aware about hessian than going for a new module, but there might be a few cases, which will fail by doing that for example if you want to do a protocol transformation from hessian any other. (though this is not possible for the moment because the hessian message builder keeps the binary message as it is and is not going to build the message). Thanks, Ruwan On Mon, Mar 16, 2009 at 1:31 AM, Andreas Veithen andreas.veit...@gmail.com wrote: On Sun, Mar 15, 2009 at 20:36, Hubert, Eric eric.hub...@foxmobile.com wrote: For two reasons: 1. Message formatters should be protocol independent (even if they have access to the full MessageContext). This is currently not the case. Whereas the rest of Synapse is totally unaware of any Hessian specifics, the Hessian Builder/Formatter pair is actually the protocol dependent implementation. It is only used for Hessian Messages and has to be configured (activated) in axis2.xml for the specific content type. My statement was not precise enough. What I wanted to say is that message formatters should be _transport_ protocol independent. On the other hand, as you point out, they implement a specific _application_ protocol. BTW, is Hessian used on other transport protocols, such as JMS? 2. Probably when the message formatter is invoked, it is already too late to set the HTTP status code. Excactly! Thats the definite reason. The whole http headers are already written when it comes to the formatter. See HttpCoreNIOSender.sendAsyncResponse(): worker.getServiceHandler().commitResponse(worker.getConn(), response); // ... OutputStream out = worker.getOutputStream(); //.. messageFormatter.writeTo(msgContext, format, out, false); Regards, Eric - 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 -- 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: svn commit: r753144 - in /synapse/trunk/java/modules: core/src/main/java/org/apache/synapse/mediators/builtin/ core/src/main/java/org/apache/synapse/mediators/db/ core/src/main/java/org/apache/syn
Indika, I may wrong but state full means outcome of the current request may be depend on what previous requests did. If it is session ware, then it depends on previous requests on the current session. Keeping life cycle state (initialized, destroyed), not relate with above thing. I agree the term state might not be properly chosen by Ruwan, but his explanation of his concerns was understandable at least understandable to me and somehow I seem to have the same concerns. me, if it is good, if we can enforce that, all the mediators need to be properly initialized and destroyed. With this change you do not enforce anything. You could only enforce this by making the methods abstract. Any empty implementation enforces nothing, or? Minimally, any mediator that is an abstract mediator (it is a mediator with some common behaviors), need to properly initialized and destroyed (currently it is not there). Why? What about the POJOCommandMediator? If this would be the case the class name of AbstractMediator should reflect this and the lifecycle methods should be abstract. It is possible to fill the blank with some useful things. For example, cache SynapseEnvironment or Axis2 Configuration Context... There are many mediators that try to access these with in mediate method by casting to axi2 message context, then get axi2 configuration context, then get synapse environment,etc …. Can completely eliminate those codes. Keeping SynapseEnvironment is never bad thing….. If there is really a some common code in conjunction with managed lifecycle it might be a better idea to create a new abstract class extending from AbstractMediator implementing those methods and letting all mediators needing a lifecycle extending from those. Having had only a short look at some Synapse mediators I actually doubt the benefit. Hmmm, I did not get the full meaning of your last two sentences. I'm quite new to the Synapse code, which maybe the reason. But if many mediators are doing the same thing (and this does not sound to be lifecyle-dependend) then you may implement some common functionality in AbstractMediator and use this, or? Regards, Eric
Usage of @deprecated
Hi Synapse-Devs, While having a look at the AbstractMediator class I noticed all the deprecated methods. From my perspective deprecating methods to keep backward compatibility is generally a good thing. Unfortunately you didn't use the @deprecated JavaDoc-Tag to provide information about the reason and/or what to use instead. If someone is aware of the details it would be helpful to add this information there and always include it in the future while deprecating methods. Thanks, Eric
RE: Usage of @deprecated
Many thanks Andreas! Good point. I've modified the Javadoc to include the relevant @deprecated tags. Now reading the JavaDoc everything is clear.
RE: jline
Thanks, I will double check. In which pom is the dependency declared? I don't think it is a transitive one... Added the dependency to the pom of the synapse core module fixed my problem. Anyway thanks for checking! Regards, Eric -Original Message- From: indika kumara [mailto:indika.k...@gmail.com] Sent: Saturday, March 14, 2009 4:48 PM To: dev@synapse.apache.org Subject: Re: jline Eric I just checked . I didn't get build issue. Thanks Indika On Sat, Mar 14, 2009 at 7:53 PM, Hubert, Eric eric.hub...@foxmobile.com wrote: Indika, Are we currently missing a core dependency for jline? Something like: dependency groupIdjline/groupId artifactIdjline/artifactId version0.9.94/version /dependency Or did I make a mistake in updating some pom? Regards, Eric - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Offer to support Synapse development
Hi Andreas, Is it possible to tell Findbugs and/or PMD to ignore specific false positives using annotations (either Javadoc style or Java 5)? Sorry, I completely forgot to answer this question. In addition to specifying a specific ruleset it is possible to deactivate a rule in a specific context. This should be accompanied with a comment, of course. As PMD works on the source code it is possible to use the normal @SuppressWarnings annotation in the following format @SuppressWarnings(PMD.rulename) If you are working with Eclipse, you then have to ignore a warning of an unknown suppression, or something like that (Eclipse compiler setting). PMD recognizes this suppression. Also see: http://pmd.sourceforge.net/suppressing.html For Findbugs this can obviously not work, as Findbugs operates on the bytecode and the java.lang.SuppressWarnings annotation has source not runtime rentention. Therefore Findbugs defines its own Annotation: @edu.umd.cs.findbugs.annotations.SuppressWarnings(value=rulename) Also see: http://findbugs.sourceforge.net/manual/annotations.html Regards, Eric
Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi all,
if someone wants to use the FaultMediator in conjunction with Hessian messages
he has to know that he to set the HTTP status code to 200, after using the
FaultMediator and before using the SendMediator.
Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once
created a possibility to override this value using a property of scope Axis2.
So declaratively this is possible in synapse.xml via adding the following
configuration block:
syn:switch source=get-property('transport', 'Content-Type')
syn:case regex=x-application/hessian
syn:property name=HTTP_SC value=200 scope=axis2/
/syn:case
/syn:switch
The HessianFormatter transforms the SOAPFault to a Hessian fault and writes a
valid Hessian fault message to the client, which deserializes the fault message
to a HessianServiceException with the proper message.
This only works if the HTTP status code is 200. Any other messages will not be
deserialized by the Hessian Client libraries.
I guess most people trying out the Hessian support would stumple over this
issue. I see two possibilities and would like to here your opinion.
a) Document this behaviour and the needed configuration online.
b) Extend the FaultMediator to set this property programmatically depending on
the content-type header.
I see advantages and disadvantages with both approaches. Currently the
FaultMediator is already handling the differences between SOAP 1.1, SOAP 1.2
and POX. This would need three of four more lines as well as the duplication or
a move of a content-type constant for x-application/hessian as for sure a
dependency from the core to the extensions module must not exist.
Anyone having a clever option c in mind? Comments are welcome!
Regards,
Eric
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi Ruwan,
yes I certainly understand this concern and am also looking for a clean
approach. You are right it is basically the question whether the fault
mediator is allowed to contain application protocol specific logic
besides the already existing SOAP-logic (which is actually also
application protocol specific logic).
It is not really the core which would be aware of the hessian protocol,
but a mediator being part of the current synapse core Maven module. I
think subclassing the FaultMediator to create a Hessian-aware mediator
in the extensions-module would be possible, but would not be worth the
code overhead. I will continue to think about it...
Thanks,
Eric
From: Ruwan Linton [mailto:ruwan.lin...@gmail.com]
Sent: Saturday, March 14, 2009 7:44 PM
To: dev@synapse.apache.org
Subject: Re: Creating HessianFaults using
FaultMediator/HessianMessageFormatter
Hi Eric,
While fixing the HTTP status code issue which we found earlier, I have
thought of many ways of fixing this, but all of that ended up with
making the synapse core aware of hessian behaviors which is sort of not
good.
There fore I only see the option (a) as the possible approach that we
can take, may be we could add this bit of logic to the Fault mediator
because that is a mediator but not the core of synapse, so the fault
mediator is aware of the hessian protocol.
Thanks,
Ruwan
On Sat, Mar 14, 2009 at 11:43 PM, Hubert, Eric
eric.hub...@foxmobile.com wrote:
Hi all,
if someone wants to use the FaultMediator in conjunction with Hessian
messages he has to know that he to set the HTTP status code to 200,
after using the FaultMediator and before using the SendMediator.
Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once
created a possibility to override this value using a property of scope
Axis2.
So declaratively this is possible in synapse.xml via adding the
following configuration block:
syn:switch source=get-property('transport', 'Content-Type')
syn:case regex=x-application/hessian
syn:property name=HTTP_SC value=200 scope=axis2/
/syn:case
/syn:switch
The HessianFormatter transforms the SOAPFault to a Hessian fault and
writes a valid Hessian fault message to the client, which deserializes
the fault message to a HessianServiceException with the proper message.
This only works if the HTTP status code is 200. Any other messages will
not be deserialized by the Hessian Client libraries.
I guess most people trying out the Hessian support would stumple over
this issue. I see two possibilities and would like to here your opinion.
a) Document this behaviour and the needed configuration online.
b) Extend the FaultMediator to set this property programmatically
depending on the content-type header.
I see advantages and disadvantages with both approaches. Currently the
FaultMediator is already handling the differences between SOAP 1.1, SOAP
1.2 and POX. This would need three of four more lines as well as the
duplication or a move of a content-type constant for
x-application/hessian as for sure a dependency from the core to the
extensions module must not exist.
Anyone having a clever option c in mind? Comments are welcome!
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: Creating HessianFaults using FaultMediator/HessianMessageFormatter
I thought it might be useful for discussion to also have some sample code to
illustrate b).
Please find attached a quick implementation showing the idea.
Regards,
Eric
Hi all,
if someone wants to use the FaultMediator in conjunction with Hessian
messages he has to know that he to set the HTTP status code to 200, after
using the FaultMediator and before using the SendMediator.
Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once
created a possibility to override this value using a property of scope
Axis2.
So declaratively this is possible in synapse.xml via adding the following
configuration block:
syn:switch source=get-property('transport', 'Content-Type')
syn:case regex=x-application/hessian
syn:property name=HTTP_SC value=200 scope=axis2/
/syn:case
/syn:switch
The HessianFormatter transforms the SOAPFault to a Hessian fault and
writes a valid Hessian fault message to the client, which deserializes the
fault message to a HessianServiceException with the proper message.
This only works if the HTTP status code is 200. Any other messages will
not be deserialized by the Hessian Client libraries.
I guess most people trying out the Hessian support would stumple over this
issue. I see two possibilities and would like to here your opinion.
a) Document this behaviour and the needed configuration online.
b) Extend the FaultMediator to set this property programmatically
depending on the content-type header.
I see advantages and disadvantages with both approaches. Currently the
FaultMediator is already handling the differences between SOAP 1.1, SOAP
1.2 and POX. This would need three of four more lines as well as the
duplication or a move of a content-type constant for x-
application/hessian as for sure a dependency from the core to the
extensions module must not exist.
Anyone having a clever option c in mind? Comments are welcome!
Regards,
Eric
FaultMediator.java.patch
Description: FaultMediator.java.patch
-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Problem with empty load balance groups
Two solutions would be acceptable to me: a) The ESB does not start if a load balancing group is empty and output the name(s) of the empty laodbalance groups. This approach might cause compatibility issues with existing (mis)configurations. Also unused configuration parts would cause Synapse not to start. On the other hand this is fail fast and if we would have a schema, this configuration would probably be disallowed. b) At runtime the problem is detected and a fault is sent to the client indicating that no member of a loadbalancing group are available. Do you have other solutions in mind? What solution do you prefer? I would certainly prefer option A.. it would be easier to implement and also better in dealing with the issue than at runtime. Ok, I will go this road. If you currently set log4j level to debug for synapse core, you already have this behaviour - even though surely not intended. ;-) NPE during debug output in LoadbalanceEndpoint.setAlgorithm() Regards, Eric
RE: Offer to support Synapse development
Hi Ruwan, yes you are able to modify the rule sets. Starting with default rulesets on grown code is always problematic as you might get swamped with violations of different priorities. Even though you can filter by priorities it maybe to much what you get. Besides this Findbugs and PMD may detect false positives under some situations. Nevertheless the output is very valuable. You just should not concentrate to much on absolute values. PMD and Findbugs does not need much configuration. Checkstyle should get a custom ruleset according to the projects needs. Otherwise it may really produce a lot of useless output. Of course I would be willing to help you to get the configuration right. I’m sure it will further improve the code quality in the long run. To get something started we would not need to setup a doc job for the whole project. I think we could also start with a small Maven module like experimental or handler before jumping on the big ones like transport or core. What do you think? Yes I’m aware of the ASF model of becoming a committer. This is a very solid and useful model. To be honest, sometimes I whish someone would establish the same system in the business world. ;-) I will continue to focus on small individual patches. Thanks, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, March 09, 2009 12:05 AM To: dev@synapse.apache.org Subject: Re: Offer to support Synapse development Hi Eric, It is really nice to see you getting on to the code... We have integrated the FindBugs, Checkstyle and PMD through the respective maven plugins and found that they were by default giving a set of issues but after a going through those I have realized most of them are not really issues, but of couse we have found a set of good issues that we had as well. I am sure that we can configure the level of error checking but I didn't tried to go along that path (well, I would say the time factor stopped me in going that line). Even though we tried this we never get this committed into the svn and got it to run continuously. I think we better integrate these with correct configurations to get best results and if you could help us getting there that would be of utmost help. I think you will have to go through the JIRA and patches model for the contributions for the moment until you become a committer, well that is how generally apache operates (you may already know this), and I would prefer to have small patches on one concern than a patch touching most of the files. Thanks for the contribution, and it is very valuable for the evolution of this project into a success product. Thanks, Ruwan On Mon, Mar 9, 2009 at 3:55 AM, Hubert, Eric eric.hub...@foxmobile.com wrote: Hi Synapse-Devs, Since more than a year I've been actively following the Synapse users and dev mailings lists. Some of you may have also noticed my efforts to improve Synapse from a user's perspective by reporting bugs and submitting feature requests including implementation ideas and minor code contributions. I would like to extend this support in the direction of active code development. As a starting point I checked out Synapse trunk, imported the projects into Eclipse and activated my normal development toolset (Findbugs, PMD, Checkstyle, EclEmma). Well by having a look at the number of potential code problems I think there is some room for improvements (as always). ;-) I have seen you guys are using the great Hudson project as your CI environment: http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules Have you ever considered setting up a doc job for Synapse using the following plugins: http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin From my personal experiences I can say it's really worth to use it, especially to always have the trends of those metrics available. You will find some examples on the pages presented above. My personal interests regarding Synapse concentrate on the http transports, Hessian application protocol usage, server management, monitoring, the improvement of error logs for faster problem recognition, full JDK 6 compatibility, and the separation of implementation and API supporting custom development of mediators. Besides this I'm willing to contribute also in other areas, but those are the ones my focus is on. The only question is where to start? I don't think it makes much sense to provide dozens of small code fixes in a great number of patches (per class or package). Too much work during review. A big patch touching too much files is even worse. Small and independent changes are important for a suitable review process. Thus I think it is best to start
RE: Offer to support Synapse development
Hi all, This is great news.. I truly appreciate all your help in the past to improve the NIO transport, endpoints and JMX support Thanks for the positive feedback! Do you have any specific JDK 6 stuff in mind? The main issue I see is with the BSF mediator.. but I would still like to continue the JDK 1.5 support going forward Sorry for being not precise enough. I also would like to keep Java 5 compatibility. So it is not about introduction new fancy Java 6 features in the code. It's basically about being able to a) run Synapse in production using Java 6 (I don't think there is any issue other than the BSF mediator) b) build Synapse and run tests using Java 6 runtime environment (maybe here it is also only the BSFMediator test which fails; I did not try so far) Regards, Eric
Changes in AbstractMediatorFactory
Hi all, while developing and testing the fault detection in the HessianMessageBuilder I'll noticed that I had to change our custom developed code. The question is whether the code we use is considered part of the API of Synapse or not. AbstractmediatorFactory once exposed a protected method called processTraceState() which had been renamed to processAuditStatus(). This method is not called inside any other method. So each concrete Factory has to call it directly. Thus I would consider it to be part of the API as the user may need to write a factory to process custom config snippets and call it in the create method. If this is the case we might think of applying something like the attached patch to keep custom mediator development compatible for at least one version. What do you think? How do you normally handle something like this? Regards, Eric AbstractMediatorFactory.java.patch Description: AbstractMediatorFactory.java.patch - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Changes in AbstractMediatorFactory
I prefer to support the compatibility.. I've myself encountered this issue when developing custom mediators.. In future, we should always try to deprecate old methods and then delete them in the next major version So +1 for your patch.. you will need to attach it to a JIRA to grant the license to use :-) Yes, done (SYNAPSE-516). Just wanted to ask on the dev list in advance. Could have been that I misinterpreted something. Thanks, Eric
RE: VFS - Synapse Memory Leak
Hi Andreas, No, basically the code would take an OMElement and return a Reader that represents the text content of that element. It would take care of doing this in an optimal way (constant memory usage and minimal usage of intermediate buffers), i.e. it would provide the same functionality than new StringReader(omElement.getText()), but without loading the entire data into memory. We already do something like this in the PlainTextFormatter, but here the idea is to encapsulate that nicely behind a Reader implementation. Note that this is not at all transport specific and would work with any OMElement. +1 sounds very useful
Offer to support Synapse development
Hi Synapse-Devs, Since more than a year I've been actively following the Synapse users and dev mailings lists. Some of you may have also noticed my efforts to improve Synapse from a user's perspective by reporting bugs and submitting feature requests including implementation ideas and minor code contributions. I would like to extend this support in the direction of active code development. As a starting point I checked out Synapse trunk, imported the projects into Eclipse and activated my normal development toolset (Findbugs, PMD, Checkstyle, EclEmma). Well by having a look at the number of potential code problems I think there is some room for improvements (as always). ;-) I have seen you guys are using the great Hudson project as your CI environment: http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/modules Have you ever considered setting up a doc job for Synapse using the following plugins: http://wiki.hudson-ci.org/display/HUDSON/FindBugs+Plugin http://wiki.hudson-ci.org/display/HUDSON/PMD+Plugin http://wiki.hudson-ci.org/display/HUDSON/Checkstyle+Plugin http://wiki.hudson-ci.org/display/HUDSON/Cobertura+Plugin http://wiki.hudson-ci.org/display/HUDSON/DRY+Plugin From my personal experiences I can say it's really worth to use it, especially to always have the trends of those metrics available. You will find some examples on the pages presented above. My personal interests regarding Synapse concentrate on the http transports, Hessian application protocol usage, server management, monitoring, the improvement of error logs for faster problem recognition, full JDK 6 compatibility, and the separation of implementation and API supporting custom development of mediators. Besides this I'm willing to contribute also in other areas, but those are the ones my focus is on. The only question is where to start? I don't think it makes much sense to provide dozens of small code fixes in a great number of patches (per class or package). Too much work during review. A big patch touching too much files is even worse. Small and independent changes are important for a suitable review process. Thus I think it is best to start with small, independent features provided as a patch. As the very first start I would like to contribute a small enhancement to the Hessian message builder to detect fault messages. So I created a new JIRA for it: https://issues.apache.org/jira/browse/SYNAPSE-514 I tried to follow the conventions I have found. It would be nice if someone could review the patch and provide feedback. If you find any problems, I'll correct them. Regards, Eric
RE: API-Question: MessageContext.isFaultResponse()
Hi Asankha, thanks for your detailed and very helpful reply. Please find my comments inline! MessageContext.isFaultResponse() This seems like a left over and unused/unwanted API method that we need to clean up.. I would consider a cleanup along with the move of the core API's into a separate package as proposed by you, so that users will only use the public API. This would also help us maintain backwards compatibility at least in future, over methods in the public API. With separate package I suppose technically you are associating a separate Maven artefact (JAR-File), right? Yes, this way we can encourage people extending Synapse to only use the public API and save them from unknown compatibility issues. If the users decide to use any internal API then this at least gets obvious to them and they recognize that they are on a (wrong/dangerous) road and should ask on the dev list about changing their approach or letting change the public API. ;-) In order to detect errors for other protocols, like the binary Hessian protocol, things get even more complicated. At mediation time, I'm rather late to detect those, as I would need access to the binary stream. For example SOAP 1.1/1.2 and REST over http/s should use HTTP 500 for error responses. I guess Hessian should too, and most other protocols Your guess regarding the Hessian protocol is unfortunately wrong. Hessian does not differentiate between normal and erroneous responses via an HTTP status code. Faults are also send as HTTP 200 and Synapse currently violates the Hessian protocol spec in this regard. Hessian - this would not be possible with the current implementation, although we could surely write a smart hessian builder, that can just read the first few bytes of the binary message and detect this :-) ! Yes, this was exactly what I wanted to do. But I don't want to end up with our own version of an improved Hessian message builder/formatter pair. So I would suggest we implement those needed changes and submit a patch. I will also take a look at the HTTP response code handling as this is currently not correct for Hessian faults (also for the self generated ones via the makeFault-mediator). I think your idea and approach is correct and good.. Ok, with this statement it makes sense for me to proceed. I just did not want to run in the wrong direction. Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Time for a release??
Security.setProperty(networkaddress.cache.ttl, myValue1); Security.setProperty(networkaddress.cache.negative.ttl, myValue2); So I believe you do not want to set this to a specific hard coded value in the startup scripts? Yes Asankha, you are right with your assumption. :-) Setting the corresponding Java System properties at startup works, but there is no optimal value for all situations. The default of caching forever is generally a good thing. Only in certain situations I want to be able to *temporally* change those values without having to restart the JVM. Currently the workaround I see (if having a loadbalanced cluster in place) per node before and after any IP change: - switch to maintenance - do JVM-restart with changed values (incorporated into startup scripts) With Java 6 I can have a small management console, iterate over all nodes and call a simple MBean method in one single step without introducing much overhead - seems to work pretty well. Just another question: If not using script mediator, is it save to use Java 6 with Synapse? Does someone already use this combination in production? Do all other Unit-Tests pass? Regards, Eric
RE: How to debug Synapse
IDE based debugging is kinda painful to setup, isn't using JDB (command line) as stated above easier? I'd like to have an opinion on this. Hmm, maybe I misunderstand something regarding IDE based debugging, but any IDE I'm aware of supports remote debugging. And it is very easy to setup. So where is the problem to start the server in debug mode and attach a debugger from your IDE? I mean there is no big difference whether you start a server locally in debug mode (in a separate JVM) or start the main class directly from your IDE. Using the first approach you have to configure less and are closer to a real server start. Just my 0.2 cents, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Moving of the transports - status
Hi Andreas, For the transports in Synapse it would imply splitting up the synapse-transports module into several Maven modules. Maybe the first step is to get rid of the dependencies in Synapse's master POM and declare them at module level as we discussed sime time ago in SYNAPSE-396. From my point of view this is a very good idea as a first step preparing further actions. Speaking as a user of Synapse I would like to see a flexible way to decide which transports to use thus automatically reducing the dependencies to what is actually needed. Regards, Eric
RE: [HttpCore] Next release; was Re: [jira] Commented: (HTTPCORE-172)
Hi Oleg, just wanted to ask you what are your plans for releasing HttpCore 4.0 beta3? Do you plan to release it any time soon? Regards, Eric I try to make sure there is a release every three months or so. End of September or mid October would be the next planned release time frame. We can always cut a release sooner if there is enough interest. We are using Synapse and as Jason I'm very interested in the fixes of HTTPCORE-170 and HTTPCORE-172 which will go in HttpCore 4.0 beta3. But as the area of changes is quite limited, I guess the Synapse team will just patch those classes and update to HttpCore 4.0 beta3 at the moment it becomes available. If I'm not wrong the Synapse team is going to release the next beta release end of October so this seems to perfectly align with your release plans. Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r672650 - in /synapse/trunk/java/modules/core/src: main/java/org/apache/synapse/config/xml/ main/java/org/apache/synapse/mediators/transform/ test/java/org/apache/synapse/config/xml/
Hi,
yes, marking a fault as a response by default sounds also reasonable to
me. If there are really cases where this is not what you want, you can
simply leave the code as it is, but just initialize the markAsResponse
to true by default so the user would only need to configure something if
he wants to change the default to not send the fault as a response.
Removing the To header programmatically here if no ReplyTo exists sounds
like a good idea. This would further reduce the need of configuration.
Good ideas Asankha, I'm also interested whether Ruwan has some cases in
mind, where this would not be a desired behaviour.
Regards,
Eric
From: Asankha C. Perera [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2008 8:12 AM
To: dev@synapse.apache.org
Subject: Re: svn commit: r672650 - in
/synapse/trunk/java/modules/core/src:
main/java/org/apache/synapse/config/xml/
main/java/org/apache/synapse/mediators/transform/
test/java/org/apache/synapse/config/xml/
Ruwan
I think by default, we should mark a fault as a response? Any reason to
not do this?
Also for the below code, shall we check if a ReplyTo exists, and else
remove the 'To' header like we now do in config?
thanks
asankha
[EMAIL PROTECTED] wrote:
Author: ruwan
Date: Sun Jun 29 10:33:49 2008
New Revision: 672650
Fixing the issue SYNAPSE-367
now the makeFault will optionally mark the message as a response when
the response attribute value is set to true
==
---
synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/mediato
rs/transform/FaultMediator.java (original)
+++
synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/mediato
rs/transform/FaultMediator.java Sun Jun 29 10:33:49 2008
@@ -114,23 +118,31 @@
...
+// if the message has to be marked as a response mark it as
response
+if (markAsResponse) {
+synCtx.setResponse(true);
+synCtx.setTo(synCtx.getReplyTo());
+}
+
+return true;
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
RE: Making force HTTP 1.0 a part of the endpoint definition?
Hi all, sounds like an interersting idea. We actually define it in exactly that way on an endpoint level in our custom repository and generate a synapse.xml containing the property mediator to set this property. It would be more straightforward to be able to set this at the endpoint level. There one should consider LoadbalanceEndpoints as a kind of container from which child endpoints should inherit the defaults. Right now some properties need to be specified at the individual endpoint level like suspend duration and timeout. Most of the time all endpoints of a loadbalancing group should be handled in the same way (either all http 1.0 or all http 1.1 etc.) Just a thought... Regards, Eric From: Asankha C. Perera [mailto:[EMAIL PROTECTED] Sent: Thursday, July 17, 2008 1:08 PM To: dev@synapse.apache.org Subject: Re: Making force HTTP 1.0 a part of the endpoint definition? Paul Infact I was thinking of the same thing.. and was suggesting to Ruwan about allowing properties to be set at an Endpoint level.. and the most useful properties could be for HTTP 1.0. use of just the PATH instead of full URL, setting JMS reply destinations etc.. asankha Paul Fremantle wrote: I'm generally against hard-coding transport specifics, but the high number of people running into trouble with HTTP1.0-only servers makes me wonder if its worth us adding a flag to the endpoint definition to force HTTP 1.0? Thoughts? Paul -- Asankha C. Perera WSO2 - http://wso2.org http://esbmagic.blogspot.com
RE: Possible Causes for Connection reset by peer when using NIO
Hi Asankha, thanks for your reply as well! Please see my comments below! One thing you could analyze is the TCP socket timeout times in the different environments.. Hmm, TCP socket timeout should be the same, but I will investigate. Also our response times are pretty low. Average of 10-15 ms with a maximum of less than 7 seconds so far (happened only a few time since three days). nhttp.properties into the ESB classpath, and add the following line into it, you can change the Synapse socket timeout http.socket.timeout=6 - this is in ms. Maybe you can do a similar thing with the BEA server.. This brings me to a new idea and I what like to hear what you think about. What if I would decrease the value for http.socket.timeout to 2 for Synapse, so to be definitely lower than the one on the server side. What would be the expected result? Would I see another exception, if the timeout on the Synapse side is reached? Maybe I'm wrong and there are requests which take longer, even if they are neither listed in our statistics nor in the http access logs of the Bea server. Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Possible Causes for Connection reset by peer when using NIO
Hi Asankha, I think this is a good idea.. as we will close the session on our own without an exception, and then BEA can close it from that side Ok, then I will go ahead and try this out. Is there a way to check whether this property has been applied properly by Synapse? Some JMX-monitoring possibility or so? Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Possible Causes for Connection reset by peer when using NIO
Hi devs! first of all I'd like to apologize for posting a user-problem to two dev-lists. I only did this as have not much background knowledge of the NIO implementation and think a solid understanding of NIO is necessary to help tackling our problem. We are using the WSO2 ESB which is based on Apache Synapse, Apache Axis2 and the HTTP Core NIO module. As the stacktrace only contains http-nio details, I cc'ed the http components dev list. Hopefully someone can help out. When sending about 3000 Hessian-requests per hour from clients (Tomcat) over the ESB (Synapse 1.2 running on JDK 1.5.15, Linux 2.6.23.1-amd64-75) to a Bea Weblogic 8.1 we see about 1 to 10 exceptions of type java.io.IOException: Connection reset by peer in the ESB-log. If I understand it right the ESB then executes a failover to the next service node as we are using a load balancing group. So the client is not affected, but the endpoint with the failure will be marked as inactive. The problem is I don't understand the cause of this exception. It occurs during the read on a Socket-Channel. So I think the server might close the connection while the ESB is reading. But maybe internally some kind of pool is used and a connection can change to some abnormal state? We have seen such Exceptions before when we were using HTTP 1.1 in combination with the Bea Weblogic server. Very likely an issue with HTTP keepalive (persistent connections). So for any connection to a Bea service we use the property mediator of Synapse to change the connection ESB - Bea to use HTTP 1.0: syn:property name=FORCE_HTTP_1.0 value=true scope=axis2 / Since then we hadn't seen this exception again. But now switching to another environment we see this exception again, but only for Hessian services. I have no clue what else could cause this exception. How can we detect the cause? How to narrow down possible causes, if there are different possibilities. I don't expect any network outages to be the reason, as other services (SOAP)-based are working pretty well. The exact exception we are getting is: java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) at org.apache.http.impl.nio.reactor.SessionInputBufferImpl.fill(SessionInputBufferImpl.java:85) at org.apache.http.impl.nio.codecs.AbstractMessageParser.fillBuffer(AbstractMessageParser.java:97) at org.apache.http.impl.nio.DefaultNHttpClientConnection.consumeInput(DefaultNHttpClientConnection.java:113) at org.apache.http.impl.nio.DefaultClientIOEventDispatch.inputReady(DefaultClientIOEventDispatch.java:99) at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:98) at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:195) at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:180) at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:142) at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:70) at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:318) This exception occurs consistently a few time per hour on every possible combination of client node, esb node and service endpoint node. Any pointer or idea is greatly appreciated. Thanks a lot in advance! Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: JMS transport specs/documentation
Hi Rajith, it is not much about newer application servers. In fact it is a requirement of the Java EE specification. In the Java EE 1.3 spec it was only forbidden in the EJB container, if I'm not wrong. At least the wording had not been very strict on this. Since J2EE 1.4 all J2EE/JEE servers may throw a JMSException, if an application violates these requirements. This section is more or less unchanged in the Java EE specification, v5. Some application server out there changed their behaviour at some point. Please see below for more details on this! We also have plans to adhere to the proposed binding for SOAP over JMS specification http://mail-archives.apache.org/mod_mbox/ws-axis-dev/200701.mbox/[EMAIL PROTECTED] . At the same time, we need to update our code to not use setMessageListener() etc. which the newer JEE app servers (such as WebSphere) does not allow.. Sorry I am not aware of this. Why is this not allowed? Any pointer to this ? I can give you at least one pointer: Java(tm) 2 Platform Enterprise Edition Specification, v1.4 (J2EE.6.6 Java(tm) Message Service (JMS) 1.1 Requirements). [...] The following methods may only be used by application components executing in the application client container: * javax.jms.Session method setMessageListener * javax.jms.Session method getMessageListener * javax.jms.Session method run * javax.jms.QueueConnection method createConnectionConsumer * javax.jms.TopicConnection method createConnectionConsumer * javax.jms.TopicConnection method createDurableConnectionConsumer * javax.jms.MessageConsumer method getMessageListener * javax.jms.MessageConsumer method setMessageListener * javax.jms.Connection method setExceptionListener * javax.jms.Connection method stop * javax.jms.Connection method setClientID A J2EE container may throw a JMSException (if allowed by the method) if the application component violates these restrictions. Application components in the web and EJB containers must not attempt to create more than one active (not closed) Session object per connection. An attempt to use the Connection object's createSession method when an active Session object exists for that connection should be prohibited by the container. The container may throw a JMSException if the application component violates this restriction. [...] The JMS specification is available at http://java.sun.com/products/jms. Regards, Eric winmail.dat- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Improving the loadbalancing support
Hi all, today I would like to discuss some options to improve the load balancing support of Apache Synapse. As not all of my ideas have settled, I may miss some pieces of the current implementation and would like to get some feedback about my ideas, I decided to not create a JIRA for that immediately. Though, after our discussion I would like to summarize the results in a JIRA. 1) Where can I review the status of the endpoints of a loadbalance group? It should be possible to query the status of each endpoint via JMX. It should also be possible to get the number of configured as well as active endpoints of a load balance group via JMX. This way it will be possible to use some meaningful external monitoring. For example the user could define an alert if only 2 nodes are left or the ratio of available nodes is less then 20% or something like this. 2) Another very useful feature would be the possibility to manually deactivate an endpoint of a load balancing group. If I understand it correctly right now you have to remove the endpoint from the group and restart your server (or cluster gracefully). Not very nice. To implement this, it might make sense to differ between three states: active, deactivated and manually deactivated. A manually deactivated endpoint can only be manually reactivated. Automatic retry will not be used for endpoints in that state. 3) Why did you choose the interpretation of a missing suspendDurationOnFailure that it will never be recovered after a failure? At least from my point of view this does not match my intuition and expectations. Is this really a good default value? When does a user ever want to have this effect? Do I understand this wrong, or does the user have to restart the ESB to change the status back to active? 4) A static, configurable value for suspendDurationOnFailure is better than having a hardcoded value, but is also not optimal. The user has always the problem that he tries to balance between different side effects depending on the cause of the service outage. When you think about short network instabilities and you have a small cluster (think of two nodes) you are somehow forced to keep that check interval rather short. If then suddenly a service fails for some other reason and a long period of time, this has a negative impact on the performance, as the retries happen to often. It would be much better to use a dynamic approach with a changing check interval. Start frequently (short interval of a few seconds) and increase this up to a maximum value based on the number of tries. Maybe one could come up with a general purpose function, where the user can specify the arguments. This should allow preserving the existing behaviour while also supporting better suited algorithms. 5) When *all* nodes are inactive, the ESB currently creates a fault immediately. I'm thinking whether this makes sense or not. Maybe it would be best, if the user could decide between two options: a) current behaviour b) first try all inactive endpoints until either one endpoint works, or all endpoints have been tried out once and only then issue a fault I'm not sure about this one. But the following happened during a test of a minimal service cluster with two nodes. The suspendDurationOnFailure had been set to 60 seconds. The first node had been passive due to some maintenance. So all requests have been served via the second node. Suddently a short network outage happened. The second node was marked as deactivated. It was reachable in the next second but the ESB marked it as passive. Actually the whole system was down for one minute. So you have to think about a shorter period of time for the check interval, which again would be bad for the server which has been down for maintenance. If the ESB would have done one additional round of retries, it would have detected that the endpoint in fact is already up again. Now I hope to receive a lot of comments and feedback. Maybe we can work together to make improvements in this area. Please point me to some existing functionality I may have missed! Regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
