Re: Time for a release??
Cool... So if we are to go with the proposed axis2-1.5 release our time line will depend on it, which will make synapse release date to be some where around end of November. I think it is OK... Thanks, Ruwan On Sat, Oct 18, 2008 at 8:11 AM, Glen Daniels <[EMAIL PROTECTED]> wrote: > Hm - good timing, Ruwan. ;) > > http://markmail.org/message/fluu55cg3ytld5ls?q=axis-dev > > --Glen > > > Ruwan Linton wrote: > >> BTW: is there any possibility of getting an axis2 release for this synapse >> release? My personal understanding is that, we will not be able to get an >> axis2 release to go with the synapse release. In which case can we back to >> the axis2-1.4.1 release for the synapse release? >> >> Also, we will need new transport release as well? Can that be depend >> on >> the axis2-1.4.1 as well? >> >> So what would be the time line for the release? >> >> Thanks, >> Ruwan >> >> On Fri, Oct 17, 2008 at 12:35 PM, Asankha C. Perera <[EMAIL PROTECTED] >> >wrote: >> >> Hi Eric >>> >>> 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. Cool, this is certainly valid and good approach.. >>> >>> Just another question: If not using script mediator, is it save to use Java 6 with Synapse? Yes, I believe so.. however, I guess all developers are currently on >>> JDK >>> 1.5.x by default, and we do not load test etc with JDK 1.6 yet >>> >>> Does someone already use this combination in production? Do all other Unit-Tests pass? Not to my knowledge, as we recommended JDK 1.5 for the last release.. >>> But >>> we will certainly look to support both 1.5 and 1.6 for the next release >>> of >>> Synapse 1.3 >>> >>> asankha >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/
Re: Time for a release??
Hm - good timing, Ruwan. ;) http://markmail.org/message/fluu55cg3ytld5ls?q=axis-dev --Glen Ruwan Linton wrote: BTW: is there any possibility of getting an axis2 release for this synapse release? My personal understanding is that, we will not be able to get an axis2 release to go with the synapse release. In which case can we back to the axis2-1.4.1 release for the synapse release? Also, we will need new transport release as well? Can that be depend on the axis2-1.4.1 as well? So what would be the time line for the release? Thanks, Ruwan On Fri, Oct 17, 2008 at 12:35 PM, Asankha C. Perera <[EMAIL PROTECTED]>wrote: Hi Eric 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. Cool, this is certainly valid and good approach.. Just another question: If not using script mediator, is it save to use Java 6 with Synapse? Yes, I believe so.. however, I guess all developers are currently on JDK 1.5.x by default, and we do not load test etc with JDK 1.6 yet Does someone already use this combination in production? Do all other Unit-Tests pass? Not to my knowledge, as we recommended JDK 1.5 for the last release.. But we will certainly look to support both 1.5 and 1.6 for the next release of Synapse 1.3 asankha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time for a release??
BTW: is there any possibility of getting an axis2 release for this synapse release? My personal understanding is that, we will not be able to get an axis2 release to go with the synapse release. In which case can we back to the axis2-1.4.1 release for the synapse release? Also, we will need new transport release as well? Can that be depend on the axis2-1.4.1 as well? So what would be the time line for the release? Thanks, Ruwan On Fri, Oct 17, 2008 at 12:35 PM, Asankha C. Perera <[EMAIL PROTECTED]>wrote: > Hi Eric > >> 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. >> >> > Cool, this is certainly valid and good approach.. > >> Just another question: If not using script mediator, is it save to use >> Java 6 with Synapse? >> > Yes, I believe so.. however, I guess all developers are currently on JDK > 1.5.x by default, and we do not load test etc with JDK 1.6 yet > >> Does someone already use this combination in production? Do all other >> Unit-Tests pass? >> >> > Not to my knowledge, as we recommended JDK 1.5 for the last release.. But > we will certainly look to support both 1.5 and 1.6 for the next release of > Synapse 1.3 > > asankha > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/
Re: Time for a release??
Hi Eric 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. Cool, this is certainly valid and good approach.. Just another question: If not using script mediator, is it save to use Java 6 with Synapse? Yes, I believe so.. however, I guess all developers are currently on JDK 1.5.x by default, and we do not load test etc with JDK 1.6 yet Does someone already use this combination in production? Do all other Unit-Tests pass? Not to my knowledge, as we recommended JDK 1.5 for the last release.. But we will certainly look to support both 1.5 and 1.6 for the next release of Synapse 1.3 asankha - 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: Time for a release??
Hi Eric
+1 for releasing Synapse 1.3 anytime soon.
We have seen a lot of critical bug fixes as well as nice improvements during
the last couple of months which we should share with the community.
be a good time to also visit the open JIRA's and see what else are on
the high priority list.. maybe we could ask users to vote for JIRA's..
another way to 'get them involved' some more and make sure we address
real pain points..
This is a very good point and I would like to nominate one first point. Don't
know whether we already have an issue for this. I may look around and either
raise a vote or create it...
--> Full support for Java 6
There have been a lot of users requesting this and from my point of view it
should be part of the next release.
+1 I think we should be able to run on JDK 1.5 upwards.. however the
main problem is around the script mediator.. maybe we could have two
versions of this, and let the user choose the implementation - or even
better, detect the Java VM and switch it internally..
If you are interested to hear one of my special (off-topic) reasons why I
would like to use Java 6 to run the ESB with:
Java 6 supports runtime changes of
Security.setProperty("networkaddress.cache.ttl", myValue1);
Security.setProperty("networkaddress.cache.negative.ttl", myValue2);
which are actually recognized.
With JDK 5 I could not find any way to change this dynamically. I wrote an
MBean to expose those functionality. This way I thought it would be possible to
support internal server moves where the DNS names stays constant but the IP
changes. Unfortunately without having a possibility to change the default
behaviour of caching resolved IPs forever I would have to do a JVM restart of
the ESB or configure a hard value on startup and live with the tradeoff of
increase DNS traffic. With Java 6 the runtime approach works like a charm.
If someone has an idea to solve this with Java 5 I would also be very thankful!
So I believe you do not want to set this to a specific hard coded value
in the startup scripts?
asankha
RE: Time for a release??
Hi all,
+1 for releasing Synapse 1.3 anytime soon.
We have seen a lot of critical bug fixes as well as nice improvements during
the last couple of months which we should share with the community.
> be a good time to also visit the open JIRA's and see what else are on
> the high priority list.. maybe we could ask users to vote for JIRA's..
> another way to 'get them involved' some more and make sure we address
> real pain points..
This is a very good point and I would like to nominate one first point. Don't
know whether we already have an issue for this. I may look around and either
raise a vote or create it...
--> Full support for Java 6
There have been a lot of users requesting this and from my point of view it
should be part of the next release.
If you are interested to hear one of my special (off-topic) reasons why I
would like to use Java 6 to run the ESB with:
Java 6 supports runtime changes of
Security.setProperty("networkaddress.cache.ttl", myValue1);
Security.setProperty("networkaddress.cache.negative.ttl", myValue2);
which are actually recognized.
With JDK 5 I could not find any way to change this dynamically. I wrote an
MBean to expose those functionality. This way I thought it would be possible to
support internal server moves where the DNS names stays constant but the IP
changes. Unfortunately without having a possibility to change the default
behaviour of caching resolved IPs forever I would have to do a JVM restart of
the ESB or configure a hard value on startup and live with the tradeoff of
increase DNS traffic. With Java 6 the runtime approach works like a charm.
If someone has an idea to solve this with Java 5 I would also be very thankful!
Regards,
Eric
Re: Time for a release??
Paul +1.. I just verified HttpCore beta 3 candidate yesterday.. and it would be a good time to also visit the open JIRA's and see what else are on the high priority list.. maybe we could ask users to vote for JIRA's.. another way to 'get them involved' some more and make sure we address real pain points.. asankha Paul Fremantle wrote: Folks It seems to me that a lot of good coding has happened since the last release, plus significant bug fixes. Also, Oleg is working on a new beta of HTTPCore. What are people's thoughts on having a Synapse 1.3 release? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
