Hi, The planned date for Beta1 is 28th of Sept. Beta would mean a feature and API freeze - if you think something's critical and won't meet the deadline please let me know. Following JIRAs must make it in (otherwise we'll hold the release) [1]: ISPN-2332 - Update xsite configuration file (Mircea, config/api change) ISPN-2319 - Add ability to take a site offline into x-site implementation (Mircea, required for the xsite functionality) ISPN-2316 - Distributed deadlock in StateTransferInterceptor (Dan, critical so that QA can progress with testing) ISPN-1407 - Make sure the server_list attribute of the Hot Rod Client can be updated dynamically (Galder, required by rolling upgrades functionality)

ISPN-1284 - Use synchronizations as a default transactional mode rather than XA (Mircea, small change with big impact on transactions)

On 21 Sep 2012, at 19:40, Manik Surtani wrote: Hi, The planned date for Beta1 is 28th of Sept. Beta would mean a feature and API freeze - if you think something's critical and won't meet the deadline please let me know. Following JIRAs must make it in (otherwise we'll hold the release) [1]: ISPN-2332 - Update xsite configuration file (Mircea, config/api change) ISPN-2319 - Add ability to take a site offline into x-site implementation (Mircea, required for the xsite functionality) ISPN-2316 - Distributed deadlock in StateTransferInterceptor (Dan, critical so that QA can progress with testing) ISPN-1407 - Make sure the server_list attribute of the Hot Rod Client can be updated dynamically (Galder, required by rolling upgrades functionality) This is a nice-to-have. I don't think this is critical. I think it is fair enough to ask people to reconfigure and restart their clients. Can't we rather enhance HR so that the shutting down servers would piggyback the "restart" information to the clients? When a client receives a restart response (similar to a topology change response), it restarts itself without requiring any manual work. How does it sound?

Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 21 September 2012 19:02, Mircea Markus <mircea.markus(a)jboss.com&gt; wrote: > > On 21 Sep 2012, at 19:40, Manik Surtani wrote: > > > Hi, > > The planned date for Beta1 is 28th of Sept. > Beta would mean a feature and API freeze - if you think something's critical > and won't meet the deadline please let me know. > > Following JIRAs must make it in (otherwise we'll hold the release) [1]: > > ISPN-2332 - Update xsite configuration file (Mircea, config/api change) > ISPN-2319 - Add ability to take a site offline into x-site implementation > (Mircea, required for the xsite functionality) > ISPN-2316 - Distributed deadlock in StateTransferInterceptor (Dan, critical > so that QA can progress with testing) > ISPN-1407 - Make sure the server_list attribute of the Hot Rod Client can be > updated dynamically (Galder, required by rolling upgrades functionality) > > > This is a nice-to-have. I don't think this is critical. I think it is fair > enough to ask people to reconfigure and restart their clients. > > > Can't we rather enhance HR so that the shutting down servers would piggyback > the "restart" information to the clients? When a client receives a restart > response (similar to a topology change response), it restarts itself > without requiring any manual work. How does it sound? I didn't understand what you have in mind, but nevertheless it still sounds like a nice-to-have.

Cheers, Sanne > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 25 Sep 2012, at 13:14, Galder Zamarreño wrote: >>> Can't we rather enhance HR so that the shutting down servers would piggyback >>> the "restart" information to the clients? When a client receives a restart >>> response (similar to a topology change response), it restarts itself >>> without requiring any manual work. How does it sound? >> >> I didn't understand what you have in mind, but nevertheless it still >> sounds like a nice-to-have. > > Neither I… and given how critical shutdown procedure is to make sure it's fast and does not block, I'm a bit dubious... obviously I haven't explained this right then. Let me try again :-) AFAIK ISPN-1407 [1] is needed in order to switch the HR clients connected to cluster A (running e.g. ISPN 5.2) to cluster B (running e.g. ISPN 5.3) when doing rolling upgrades. This involves an sys admin connecting to every client and manually updating this list. What I'm suggesting is a potentially more elegant approach to achieve this, by upgrading the HR protocol: - sys admin connects(JMX) to cluster A and marks the site as "upgraded to cluster B" - at this stage the HR endpoints on cluster A, when receiving requests from connected users, would also tell them(piggyback, same as we do with topology info) to connect to "cluster B" on next requests - this way the sys admin does not have to update the list of servers for all the users (there might be lots of them), but only update it once on the server side [1]ISPN-1407 - Make sure the server_list attribute of the Hot Rod Client can be updated dynamically Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I would still mark this as a nice to have, for a future version. For now, I think it is plenty reasonable to ask the sys admin to reconfigure and restart the client app. On 25 Sep 2012, at 13:29, Mircea Markus <mircea.markus(a)jboss.com&gt; wrote: > > On 25 Sep 2012, at 13:14, Galder Zamarreño wrote: > >>>> Can't we rather enhance HR so that the shutting down servers would piggyback >>>> the "restart" information to the clients? When a client receives a restart >>>> response (similar to a topology change response), it restarts itself >>>> without requiring any manual work. How does it sound? >>> >>> I didn't understand what you have in mind, but nevertheless it still >>> sounds like a nice-to-have. >> >> Neither I… and given how critical shutdown procedure is to make sure it's fast and does not block, I'm a bit dubious... > > obviously I haven't explained this right then. Let me try again :-) > > AFAIK ISPN-1407 [1] is needed in order to switch the HR clients connected to cluster A (running e.g. ISPN 5.2) to cluster B (running e.g. ISPN 5.3) when doing rolling upgrades. > This involves an sys admin connecting to every client and manually updating this list. > > What I'm suggesting is a potentially more elegant approach to achieve this, by upgrading the HR protocol: > - sys admin connects(JMX) to cluster A and marks the site as "upgraded to cluster B" > - at this stage the HR endpoints on cluster A, when receiving requests from connected users, would also tell them(piggyback, same as we do with topology info) to connect to "cluster B" on next requests > - this way the sys admin does not have to update the list of servers for all the users (there might be lots of them), but only update it once on the server side > > [1]ISPN-1407 - Make sure the server_list attribute of the Hot Rod Client can be updated dynamically > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

That would involve several things: 1. A change in the wire protocol (so not going to happen so quickly!) 2. The "old" cluster to know the new cluster's topology information, to be able to push this to clients. Possible, and would definitely do good things for user experience, but IMO can be added later as second phase.

Most of Sanne/Galder's query related changes are resolved; it still needs: - some bugfixes, especially Luksa's pull request is important - the MassIndexer is integrated, but the be effective it needs Vladimir's changes to have Map/Reduce split the work across multiple tasks.