Re: [infinispan-dev] Infinispan 6.0.0.Final is out!

Congrats ! Note that the link to "heterogeneous clusters" doesn't work On 11/19/13 9:08 PM, Adrian Nistor wrote: > Dear Infinispan community, > > We're pleased to announce the final release of Infinispan 6.0 > "Infinium". Asannounced >

Re: [infinispan-dev] merging all the github projects back?

Hi Manik, the problem the team has been facing past week is that the other modules are depending on a -SNAPSHOT version, and after having done some final touches to the modules in the core repo, we then find out that the other modules don't build anymore. This happened several times, and while it'

Re: [infinispan-dev] merging all the github projects back?

As in, for easy refactoring? True that helps. But it doesn't help you with modular releases. On 19 November 2013 15:00, Mircea Markus wrote: > That only half-solves the problem: having everything in the same IDE at > the same time is more preentive. > > On 19 Nov 2013, at 22:44, Manik Surtani

Re: [infinispan-dev] merging all the github projects back?

That only half-solves the problem: having everything in the same IDE at the same time is more preentive. > On 19 Nov 2013, at 22:44, Manik Surtani wrote: > > Can't this be achieved by checking out and building all relevant repos? This > could be scripted. > > >> On 15 November 2013 04:43,

Re: [infinispan-dev] Infinispan 6.0.0.Final is out!

Congrats. Looks like a few things went missing though: * Nothing on Twitter? * C++ docs fail - http://infinispan.org/docs/hotrod-clients/cpp/ * The fact that there is a stable but no unstable causes some weirdness in the website rendering. See the Java client - http://infinispan.org/hotrod-clien

Re: [infinispan-dev] merging all the github projects back?

Can't this be achieved by checking out and building all relevant repos? This could be scripted. On 15 November 2013 04:43, Mircea Markus wrote: > Hi guys, > > Given all the compiling problems we had since we've split in multiple > github repos (server, stores and embedded) makes me think that

[infinispan-dev] CI run for the Cpp client

Hi, Ion has access to my AWS account so he can launch new instances. >From the top of my head, for the Cpp client CI we'd need: - an RHEL5 build on every check in - an RHEL6 build on every check in - an Windows 7 (?) build on every check in Same for pull every pull requests. Work to integration

Re: [infinispan-dev] rethinking ISPN transactions

On Nov 19, 2013, at 4:49 PM, Dan Berindei wrote: > Is there any reason to use synchronization other than "it's faster"? I guess the reason for using synchronization is to invalidate (or updated) an cache. We obviously don't do that ATM, so indeed wondering if there's any point at all... Pedr

[infinispan-dev] Infinispan 6.0.0.Final is out!

Dear Infinispan community, We're pleased to announce the final release of Infinispan 6.0 "Infinium". Asannounced , this is the first Infinispan stable version to be released under the terms ofApache License v2.

Re: [infinispan-dev] configuration toProperties

On Nov 19, 2013, at 4:39 PM, Dan Berindei wrote: > I think the properties format is too closely tied to your particular use case > - in general having a long prefix on every line would actual settings harder > to see than in a structured format like XML/JSON/YAML, not easier. And if the > cac

Re: [infinispan-dev] configuration toProperties

Dennis, why would you propose it to be in a format that can be read back? It wouldn't be as simple, and you'd have to face all the complexities of supporting different version formats, etc.. Unless you've come across use cases for a JSON-like configuration? I'd go for Properties or the simple toSt

Re: [infinispan-dev] configuration toProperties

Important part of this is expressing the Configuration state as it was constructed in the JVM, either by parsing or programmatically and not omitting any of the attributes (properties) btw reflection is another way to go, I just wasn't sure what is the preferred way and where I'd put the reflec

Re: [infinispan-dev] configuration toProperties

+1 to the general idea. -1 to using Properties format (or *any* new format). Using any format that ISPN can't directly read back in ties the functionality only to your specific use case. But If it's in a configuration format that ISPN can read back in, it would be much more generally useful.

Re: [infinispan-dev] rethinking ISPN transactions

Is there any reason to use synchronization other than "it's faster"? IMO, the reasoning for removing synchronizations is the same as item 1 in your proposal, "Async options for commit/rollback". On Tue, Nov 19, 2013 at 6:35 PM, Mircea Markus wrote: > > On Nov 19, 2013, at 4:01 PM, Dan Berindei

Re: [infinispan-dev] rethinking ISPN transactions

On Nov 19, 2013, at 4:27 PM, Erik Salter wrote: > Thanks for reminding me: > > I don’t know if this has been mentioned in this thread yet, but if you’re > thinking about getting rid of 1PCs, consider the effect on xsite and some of > the options available for load-balancing data (multiple si

Re: [infinispan-dev] configuration toProperties

I think the properties format is too closely tied to your particular use case - in general having a long prefix on every line would actual settings harder to see than in a structured format like XML/JSON/YAML, not easier. And if the cache name is repeated on every line, you can't easily compare the

Re: [infinispan-dev] rethinking ISPN transactions

On Nov 19, 2013, at 4:01 PM, Dan Berindei wrote: > Maybe synchronization support is another thing that we should scrap in 7.0, > then? I'd still allow them (sync enlistment is there for a resaon), but have XA+recovery enabled by default and the batching commit should fail if the tx hasn't co

Re: [infinispan-dev] rethinking ISPN transactions

Thanks for reminding me: I don't know if this has been mentioned in this thread yet, but if you're thinking about getting rid of 1PCs, consider the effect on xsite and some of the options available for load-balancing data (multiple site masters, etc.). You still may want a 1PC in between sites

Re: [infinispan-dev] rethinking ISPN transactions

Sorry, I was confusing things - the timeout I was thinking of happened in the transaction manager itself, and it didn't matter whether we were registering a synchronization or a full XA resource. Replication timeout sounds like something that could be easily removed for commit command RPCs, but th

Re: [infinispan-dev] rethinking ISPN transactions

Maybe synchronization support is another thing that we should scrap in 7.0, then? BTW, I've also seen the transaction timeout that Radim mentioned, but only recently. I wonder if we could do anything to increase it for the stress tests. On Tue, Nov 19, 2013 at 4:40 PM, Erik Salter wrote: > > -

Re: [infinispan-dev] configuration toProperties

No need for java.util.Properties, the main feature I want is - Configuration displayable as collection of flat key-value properties - Hierarchy (e.g. l1 is under clustering) is expressed via extending the prefix and dividing by dot '.' but it would be usefull if the outputformat was easily parcea

Re: [infinispan-dev] rethinking ISPN transactions

-> this is quite a subtle aspect of JTA transactions (is Synchronisation.afterCompletion failures are not propagated to the user) - you have a very good point here, thanks! This right here has burned me very badly. I think this really needs to be called out, especially if we're using this mode r

Re: [infinispan-dev] configuration toProperties

I love the idea, especially as it happened to me to try to help someone who was running Infinispan configured via other means (like the AS7 configuration format), and it's always hard to understand how it's actually configured without knowing all the implicit default values, on a specific version (

Re: [infinispan-dev] configuration toProperties

please refer to the branch, I've rewritten the original config: https://github.com/mlinhard/infinispan/tree/t_flatconfig On 11/19/2013 02:45 PM, Michal Linhard wrote: > Hi, > > This is a configuration output format feature proposal. > > I'd like to be able to flatten the infinispan cache configura

[infinispan-dev] configuration toProperties

Hi, This is a configuration output format feature proposal. I'd like to be able to flatten the infinispan cache configuration to flat properties style so that two configurations can be easily comparable in a view that displays sorted matching properties side by side to quickly spot differences.

Re: [infinispan-dev] rethinking ISPN transactions

On Nov 19, 2013, at 7:46 AM, Radim Vansa wrote: > On 11/19/2013 03:06 AM, Mircea Markus wrote: >> On Nov 12, 2013, at 2:51 PM, Paul Ferraro wrote: >> >>> 3. Optimistic tx without Write Skew Check (WSC) - well, without WSC the transactions are not optimistic by definition - they are so

Re: [infinispan-dev] Design of Remote Hot Rod events

On 11/19/2013 02:01 PM, Emmanuel Bernard wrote: > On Tue 2013-11-19 12:23, Radim Vansa wrote: >> On 11/19/2013 09:48 AM, Emmanuel Bernard wrote: >>> I wish the design document was showing how we can achieve a general >>> purpose remote listener approach but have a step 1 that is only >>> targeting

Re: [infinispan-dev] Integration between HotRod and OGM

On 19 November 2013 12:56, Emmanuel Bernard wrote: > We could if someone puts a gun to my head. > But that would be the *only* backend that has to rely on query for its > association. Hibernate OGM has a strong design bias towards totally > controlling how CRUD is done to guarantee the consistenc

Re: [infinispan-dev] Design of Remote Hot Rod events

On Tue 2013-11-19 12:23, Radim Vansa wrote: > On 11/19/2013 09:48 AM, Emmanuel Bernard wrote: > > I wish the design document was showing how we can achieve a general > > purpose remote listener approach but have a step 1 that is only > > targeting a restricted set of listeners if you feel that it's

Re: [infinispan-dev] Integration between HotRod and OGM

We could if someone puts a gun to my head. But that would be the *only* backend that has to rely on query for its association. Hibernate OGM has a strong design bias towards totally controlling how CRUD is done to guarantee the consistency. If you introduce a search engine, all bets are off. On T

Re: [infinispan-dev] Design of Remote Hot Rod events

Dear Galder, I have read with great interest the design document your wrote for Hot Rod remote eventing [1]. In the perspective of the LEADS project, that aims at building a continuous query/streaming engine on top of Infinispan, this new feature seem very promising. However, it seems that in the

Re: [infinispan-dev] Design of Remote Hot Rod events

On 11/19/2013 09:48 AM, Emmanuel Bernard wrote: > Hey there, > > Here are a few comments based on a quick reading. > I might have totally misread or misinterpreted what was exposed, feel > free to correct me. > > ## General > > I think you are restricting the design to listeners: > > * that only li

Re: [infinispan-dev] rethinking ISPN transactions

On 11/19/2013 02:17 AM, Mircea Markus wrote: > > On Nov 12, 2013, at 3:12 PM, Pedro Ruivo wrote: > >> On 11/12/2013 11:56 AM, Galder Zamarreño wrote: >>> >>> On Nov 8, 2013, at 4:28 PM, Mircea Markus wrote: >>> Hey guys, Several things were discussed lately([1],[2],[3],[4]) aroun

Re: [infinispan-dev] Integration between HotRod and OGM

We could rely on remote queries? On 19 November 2013 10:31, Emmanuel Bernard wrote: > This message was a response to a different email discussing the composite > key approach "k1 - a1" "k1 - a2". > > The actual JIRAs are opened : > > * https://issues.jboss.org/browse/ISPN-3732 > * https://issues.

Re: [infinispan-dev] Integration between HotRod and OGM

This message was a response to a different email discussing the composite key approach "k1 - a1" "k1 - a2". The actual JIRAs are opened : * https://issues.jboss.org/browse/ISPN-3732 * https://issues.jboss.org/browse/ISPN-3733 Emmanuel On Tue 2013-11-19 11:22, Emmanuel Bernard wrote: > It's an i

Re: [infinispan-dev] Integration between HotRod and OGM

It's an interesting approach that would work fine-ish for entities assuming the Hot Rod client is multi threaded and assuming the client uses Future to parallelize the calls. But it won't work for associations as we have them designed today. Each association - or more precisely the query results t

Re: [infinispan-dev] merging all the github projects back?

On Tue, Nov 19, 2013 at 11:21 AM, Martin Gencur wrote: > On 19.11.2013 09:59, Dan Berindei wrote: > >> BTW, Maven rebuilds every module in the reactor every time you run a >> build. On my machine, it takes 6 minutes to build everything in the >> Infinispan reactor. Would you really want to wait 6

Re: [infinispan-dev] merging all the github projects back?

On 19.11.2013 09:59, Dan Berindei wrote: > BTW, Maven rebuilds every module in the reactor every time you run a > build. On my machine, it takes 6 minutes to build everything in the > Infinispan reactor. Would you really want to wait 6 minutes every time > you want to test something in the serve

Re: [infinispan-dev] merging all the github projects back?

Mircea, what exactly are the problems that we want to achieve by moving everything back in a single repository? To me, the biggest problem right now is that builds take way too long, and if I integrate something in master it will take almost an entire day for TeamCity to update the status on all t

Re: [infinispan-dev] Design of Remote Hot Rod events

Hey there, Here are a few comments based on a quick reading. I might have totally misread or misinterpreted what was exposed, feel free to correct me. ## General I think you are restricting the design to listeners: * that only listen to raw entry changes * whose processing is remote * with no w