[ https://jira.jboss.org/jira/browse/JBAS-5197?page=com.atlassian.jira.plug... ] Brian Stansberry updated JBAS-5197: ----------------------------------- Moving issues that won't happen for next AS release after 5.0.0 (whether called 5.0.1 or 5.1.0) to AS 6. It might get pulled back to a 5.x release; just don't want it on the 5.0.1/5.10 roadmap which to me at this point both might mean "the one after 5.0.0.GA". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-5197?page=com.atlassian.jira.plug... ] Andrew Oliver commented on JBAS-5197: ------------------------------------- really??? this is a pretty big functionality loss to go for a whole major release??? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-5197?page=com.atlassian.jira.plug... ] Armin Haaf commented on JBAS-5197: ---------------------------------- WOW, this is really a basic functionality for a cluster environment. We are migrating to jboss 5.1 cluster and cannot believe this problem. This will be hard to tell our customers, they have to wait another x years.... The issue is known 1 year now ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBAS-5197?page=com.atlassian.jira.plug... ] Brian Stansberry commented on JBAS-5197: ---------------------------------------- <bstansberry> dmlloyd: i don't recall if we talked about this the other day: http://community.jboss.org/wiki/RetryInterceptor <bstansberry> if yes i won't natter on <dmlloyd> no we didn't cover it <dmlloyd> well, we brushed on the existence of the problem <dmlloyd> that's about it <bstansberry> it was quite important w/ RMI-based invocation, since a cluster restart would mean any RMI stubs on the client were worthless <bstansberry> less so w/ other invokers <bstansberry> basically if the proxy couldn't invoke any servers it would try a JNDI lookup of a special location to see if it could get a new set of targets to invoke on <dmlloyd> we wouldn't need to do that for other transport types I don't think - however, the idea of retrying (or maybe blocking) until the target becomes available again might be appealing if it can be made to work <bstansberry> yeah. <bstansberry> the retrying can be done in the clustering logic itself. right now it's dumb -- if contacting a target fails it never tries again <bstansberry> it should be smarter <bstansberry> maybe mark the target suspect, so it's not chosen in load balancing decisions (until server indicates that node s/b ok) but can still be used as an option if all others are dead <dmlloyd> yeah, or some way of ranking targets or something <bstansberry> yep. so there's probably no point to a JNDI lookup; the client already has all the useful info; remoting URLs don't "break" like RMI stubs -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/JBAS-5197?page=com.atlassian.jira.plugin.sy... ] Shelly McGowan updated JBAS-5197: --------------------------------- Fix Version/s: (was: 6.0.0.Final) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira