Re: Time for Synapse 2.0?
+1 Lets add DLC as experimental and improve it for the next release. Charith, regarding the release plan I will send it shortly, assuming that we will get the Rampart release as expected. Ruwan On Sun, Sep 19, 2010 at 6:54 AM, Charith Wickramarachchi charith.dhanus...@gmail.com wrote: On Sat, Sep 18, 2010 at 4:47 PM, Hiranya Jayathilaka hiranya...@gmail.com wrote: On Sat, Sep 18, 2010 at 3:23 PM, Charith Wickramarachchi charith.dhanus...@gmail.com wrote: +1 btw is there a tentative date for this? I think we should look to get an RC out by the end of next week. We already have lot of new features and bug fixes available in the current trunk. Since i m preparing some patches for improvements in DLC and synapse referencing mechanism. The DLC implementation and the referencing mechanism are rather big changes which require certain API changes. Therefore at this point I think it's best to keep them out of the 2.0 release branch. We need to properly test these features before we release them. Hopefully Axis2 1.6 will be out soon enough and we'll be able to get a Synapse 2.1 out based on that. I suggest that we include DLC and the referencing mechanism impl in that release. Alternatively we can include only the DLC implementation with the in-memory message store and JMX MBean in the 2.0 release as an experimental feature. WDYT? +1 thanks, Charith Thanks, Hiranya Charith On Sat, Sep 18, 2010 at 2:22 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: +1, I would say we branch on early next week. Ruwan On Fri, Sep 17, 2010 at 11:29 PM, Heshan Suriyaarachchi heshan.suriyaarach...@gmail.com wrote: +1 for doing the Synapse 2.0 release based on Axis2 1.5.2. On Fri, Sep 17, 2010 at 11:05 AM, Hiranya Jayathilaka hiranya...@gmail.com wrote: Hi Folks, It's been almost 2 years since we did a Synapse release. So I think it's time. Axis2 1.5.2 will be released very soon (vote is already under way). So how about releasing Synapse 2.0 based on that? We can branch off early next week and backport it to work with Axis2 1.5.2 and be done with it within a matter of days. Synapse trunk is pretty stable right now with all tests passing. So it shouldn't be too difficult. WDYT? Thanks -- 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 -- 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.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 -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/ -- 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 -- Charith Dhanushka Wickramarachchi http://charithwiki.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.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: Shall we make the iteration run in a single thread?
So, I was thinking on the general iteration semantics, but I guess it is OK to keep it act asynchronously by default. Back ward compatibility is a fair point. I too am OK with the attribute name, but I remember there is some attribute in some place in the configuration for the same purpose with the name asynchronous and that is why I proposed it, just to be consistent. Ruwan On Sun, Sep 19, 2010 at 12:43 AM, Hiranya Jayathilaka hiranya...@gmail.comwrote: On Sat, Sep 18, 2010 at 10:16 PM, Supun Kamburugamuva supu...@gmail.com wrote: I still like the name sequential more because it is a word understandable by the common user. Looking at the original problem (iterate mediator) I too prefer the word 'sequential'. It is really a matter of executing iterator targets sequentially or not. But 'asynchronous' is ok too. Thanks, Hiranya But I'm ok with asynchronous as well. Thanks, Supun.. On Sat, Sep 18, 2010 at 9:59 PM, Hiranya Jayathilaka hiranya...@gmail.com wrote: On Sat, Sep 18, 2010 at 9:32 PM, Supun Kamburugamuva supu...@gmail.com wrote: On Sat, Sep 18, 2010 at 2:20 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: Sorry for being late, but I think the right attribute should be asynchronous and by default it is false, meaning that the iterator is sequential by default which is the general case I guess, and let the user specify if he can execute in parallel. +1 for the attribute name but why do you think we should change the default behavior? IMO most of the time users will want message fragments to be processed in parallel. Most practical scenarios are like that, isn't it? A message contains one or more similar elements that needs to be broken up and processed in parallel. Thanks, Hiranya If we use the send mediator with a sequence iteration there is no guarantee of sequential operation. Sequence operation is guaranteed only if a callout mediator is used. So it is an edge case. Also we need to think about the backward compatibility. Those were the two motivation factors behind the attribute name and default value. Thanks, Supun.. Ruwan On Thu, Sep 16, 2010 at 9:22 AM, Supun Kamburugamuva supu...@gmail.com wrote: I have done this as iterate target sequential=true|false /iterate By default sequential is false. Thanks, Supun.. On Thu, Sep 16, 2010 at 9:19 AM, Hiranya Jayathilaka hiranya...@gmail.com wrote: On Thu, Sep 16, 2010 at 9:14 AM, Supun Kamburugamuva supu...@gmail.com wrote: On Wed, Sep 15, 2010 at 7:00 PM, Hiranya Jayathilaka hiranya...@gmail.com wrote: On Wed, Sep 15, 2010 at 6:51 PM, Supun Kamburugamuva supu...@gmail.com wrote: Right now synapse iterate mediator create a new thread for each iteration. Shall we make it possible to iterate without creating a separate thread? For example lets say we want to iterate over a message and do several calls. But these calls have to be done in order. In this case this will be useful. I'm +1 for this. While implementing certain scenarios I have felt the requirement of this feature. But it must be implemented as an optional mode of operation (say sequential mode) of the mediator. By default the iterate mediator should use multiple threads to process message fragments as it does now. +1, this was the exact idea in my mind as well. How about saying iterate sequential=true/? +1 Thanks, Hiranya Thanks, Supun.. eg: iterate . sequentialMode=true /iterate By default the sequential mode should be turned off. Thanks, Hiranya Thanks, Supun.. -- Tech Lead, WSO2 Inc http://wso2.org supunk.blogspot.com -- 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 -- Tech Lead, WSO2 Inc http://wso2.org supunk.blogspot.com -- 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 -- Tech Lead, WSO2 Inc http://wso2.org supunk.blogspot.com -- Ruwan
Synapse 2.0 release plan
Folks, here is the proposed release execution plan for the 2.0 release. Release branch -- 21st of September First RC -- 23rd of September Expecting to Release on 30th of September Yes, it is really quick, but we have realized that we haven't done a public release from 2 years now, and really the trunk is pretty stable and has enormous number of new features and functionalities to go as 2.0. I expect everyones help on getting the documentation completed and any corner cases fixed. Please retain committing any experimental code into the trunk without writing to the dev list till we branch for the 2.0 release on 21st. Thanks, Ruwan -- 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
[jira] Resolved: (SYNAPSE-622) NPE in ClientConnectionDebug.java:36 when running in a failover scenario
[ https://issues.apache.org/jira/browse/SYNAPSE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruwan Linton resolved SYNAPSE-622. -- Resolution: Fixed The original issue has been fixed on the trunk and will be available on the 2.0 release NPE in ClientConnectionDebug.java:36 when running in a failover scenario - Key: SYNAPSE-622 URL: https://issues.apache.org/jira/browse/SYNAPSE-622 Project: Synapse Issue Type: Bug Components: Core Reporter: Rajika Kumarasiri Assignee: Ruwan Linton Priority: Critical Fix For: 2.0 Attachments: SYNAPSE-622.patch When I run sample #52 with one of the leaf endpoint being timeout, following NPE is thrown time to time. Once this is encountered that message is permanently lost. I'll upload a small patch which will fix the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Synapse 2.0 release plan
Just FYI, Axis2 1.5.2 release vote has passed and once the axis2 dependencies are available we can start branching. Further we are expecting a Rampart release as well. Thanks, Ruwan On Sun, Sep 19, 2010 at 3:01 PM, Ruwan Linton ruwan.lin...@gmail.comwrote: Folks, here is the proposed release execution plan for the 2.0 release. Release branch -- 21st of September First RC -- 23rd of September Expecting to Release on 30th of September Yes, it is really quick, but we have realized that we haven't done a public release from 2 years now, and really the trunk is pretty stable and has enormous number of new features and functionalities to go as 2.0. I expect everyones help on getting the documentation completed and any corner cases fixed. Please retain committing any experimental code into the trunk without writing to the dev list till we branch for the 2.0 release on 21st. Thanks, Ruwan -- 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 -- 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
[jira] Commented: (SYNAPSE-497) Synapse Spring Mediator Sample
[ https://issues.apache.org/jira/browse/SYNAPSE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12912316#action_12912316 ] Ruwan Linton commented on SYNAPSE-497: -- There are few changes required for this patch now :-) Synapse Spring Mediator Sample -- Key: SYNAPSE-497 URL: https://issues.apache.org/jira/browse/SYNAPSE-497 Project: Synapse Issue Type: Improvement Components: Extension Mediators Affects Versions: NIGHTLY Reporter: Charith Dhanushka Wickramarachchi Assignee: Ruwan Linton Priority: Minor Attachments: Spring_Mediator_Sample.patch, synapse_spring_mediator_new.patch Hi , There is no Sample for the Spring mediator in Synapse.So i have added a sample that shows How to initialize and use a Spring Bean in synapse as a Mediator.I added it as sample 440 and i updated the synapse sample guide for that. thank you, Charith Dhanushka Wickramarachchi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Resolved: (SYNAPSE-497) Synapse Spring Mediator Sample
[ https://issues.apache.org/jira/browse/SYNAPSE-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruwan Linton resolved SYNAPSE-497. -- Fix Version/s: 2.0 Resolution: Fixed Did the required changes and committed the patch Synapse Spring Mediator Sample -- Key: SYNAPSE-497 URL: https://issues.apache.org/jira/browse/SYNAPSE-497 Project: Synapse Issue Type: Improvement Components: Extension Mediators Affects Versions: NIGHTLY Reporter: Charith Dhanushka Wickramarachchi Assignee: Ruwan Linton Priority: Minor Fix For: 2.0 Attachments: Spring_Mediator_Sample.patch, synapse_spring_mediator_new.patch Hi , There is no Sample for the Spring mediator in Synapse.So i have added a sample that shows How to initialize and use a Spring Bean in synapse as a Mediator.I added it as sample 440 and i updated the synapse sample guide for that. thank you, Charith Dhanushka Wickramarachchi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter Channel for Synapse
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charith Dhanushka Wickramarachchi updated SYNAPSE-618: -- Attachment: messagestore_patch_7.diff Added improvements to the current Persistence Message store [GSoC] Implement a Dead Letter Channel for Synapse -- Key: SYNAPSE-618 URL: https://issues.apache.org/jira/browse/SYNAPSE-618 Project: Synapse Issue Type: New Feature Components: Core, Endpoints Reporter: Hiranya Jayathilaka Assignee: Hiranya Jayathilaka Fix For: FUTURE Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml Currently when Synapse attempts to send a message and if it fails, following actions can be configured to deal with the error: * Execute a fault sequence and handle the failed request gracefully * Fail-over to a different endpoint In addition to these, Synapse ESB should support the dead letter channel enterprise integration pattern to deal with various errors that might occur during mediation or while sending. With the dead letter channel, the failed message will be put into a message store in the ESB. Later the ESB can retry to send the messages in the message store. We should be able to have multiple implementations of the actual message store and should be able to configure which store to use for a particular scenario. Users should be able to implement their own message stores and plug into the ESB easily. To start with we can have a simple in-memory message store and a persisting store based on JDBC or JMS. References: http://www.eaipatterns.com/DeadLetterChannel.html https://issues.apache.org/jira/browse/SYNAPSE-263 Possible Mentors: Hiranya Jayathilaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter Channel for Synapse
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charith Dhanushka Wickramarachchi updated SYNAPSE-618: -- Attachment: messagestore_patch_7.diff Added improvements to the current Persistence Message store [GSoC] Implement a Dead Letter Channel for Synapse -- Key: SYNAPSE-618 URL: https://issues.apache.org/jira/browse/SYNAPSE-618 Project: Synapse Issue Type: New Feature Components: Core, Endpoints Reporter: Hiranya Jayathilaka Assignee: Hiranya Jayathilaka Fix For: FUTURE Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml Currently when Synapse attempts to send a message and if it fails, following actions can be configured to deal with the error: * Execute a fault sequence and handle the failed request gracefully * Fail-over to a different endpoint In addition to these, Synapse ESB should support the dead letter channel enterprise integration pattern to deal with various errors that might occur during mediation or while sending. With the dead letter channel, the failed message will be put into a message store in the ESB. Later the ESB can retry to send the messages in the message store. We should be able to have multiple implementations of the actual message store and should be able to configure which store to use for a particular scenario. Users should be able to implement their own message stores and plug into the ESB easily. To start with we can have a simple in-memory message store and a persisting store based on JDBC or JMS. References: http://www.eaipatterns.com/DeadLetterChannel.html https://issues.apache.org/jira/browse/SYNAPSE-263 Possible Mentors: Hiranya Jayathilaka -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Assigned: (SYNAPSE-662) ClientWorker overriding character encoding
[ https://issues.apache.org/jira/browse/SYNAPSE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiranya Jayathilaka reassigned SYNAPSE-662: --- Assignee: Hiranya Jayathilaka ClientWorker overriding character encoding -- Key: SYNAPSE-662 URL: https://issues.apache.org/jira/browse/SYNAPSE-662 Project: Synapse Issue Type: Bug Affects Versions: 1.2 Reporter: Myles Bunbury Assignee: Hiranya Jayathilaka Attachments: SYNAPSE-662-patch.txt The following code exists in the org.apache.synapse.transport.nhttp.ClientWorker class' run() method: responseMsgCtx.setProperty( Constants.Configuration.CHARACTER_SET_ENCODING, contentType.indexOf(HTTP.CHARSET_PARAM) 0 ? charSetEnc : MessageContext.DEFAULT_CHAR_SET_ENCODING); This fails however for the following Content-Type HTTP header: application/soap+xml; action=urn:echoResponse;charset=UTF-16 BuilderUtil.getCharSetEncoding(contentType) is called a few lines up and correctly extracts the UTF-16 character set value, but then overrides this and sets it to UTF-8. It does this because the value of org.apache.http.protocol.HTTP.CHARSET_PARAM is ; charset=. That is, it's failing because the response does not have a space between the charset parameter and the previous parameter. Reading through the HTTP specs, I haven't come across anything that says either that whitespace is permissible or not permissible here. In my view the code should therfore be flexible enough to handle either case. I would suggest simpifying the code to: responseMsgCtx.setProperty(Constants.Configuration.CHARACTER_SET_ENCODING, charSetEnc); as the BuilderUtil.getCharSetEncoding() code above the offending code seems to be sufficient at first glance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Resolved: (SYNAPSE-662) ClientWorker overriding character encoding
[ https://issues.apache.org/jira/browse/SYNAPSE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiranya Jayathilaka resolved SYNAPSE-662. - Fix Version/s: 2.0 Resolution: Fixed Checked in the patch to the trunk ClientWorker overriding character encoding -- Key: SYNAPSE-662 URL: https://issues.apache.org/jira/browse/SYNAPSE-662 Project: Synapse Issue Type: Bug Affects Versions: 1.2 Reporter: Myles Bunbury Assignee: Hiranya Jayathilaka Fix For: 2.0 Attachments: SYNAPSE-662-patch.txt The following code exists in the org.apache.synapse.transport.nhttp.ClientWorker class' run() method: responseMsgCtx.setProperty( Constants.Configuration.CHARACTER_SET_ENCODING, contentType.indexOf(HTTP.CHARSET_PARAM) 0 ? charSetEnc : MessageContext.DEFAULT_CHAR_SET_ENCODING); This fails however for the following Content-Type HTTP header: application/soap+xml; action=urn:echoResponse;charset=UTF-16 BuilderUtil.getCharSetEncoding(contentType) is called a few lines up and correctly extracts the UTF-16 character set value, but then overrides this and sets it to UTF-8. It does this because the value of org.apache.http.protocol.HTTP.CHARSET_PARAM is ; charset=. That is, it's failing because the response does not have a space between the charset parameter and the previous parameter. Reading through the HTTP specs, I haven't come across anything that says either that whitespace is permissible or not permissible here. In my view the code should therfore be flexible enough to handle either case. I would suggest simpifying the code to: responseMsgCtx.setProperty(Constants.Configuration.CHARACTER_SET_ENCODING, charSetEnc); as the BuilderUtil.getCharSetEncoding() code above the offending code seems to be sufficient at first glance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
