Re: [infinispan-dev] BoundedConcurrentHashMap

ogle.com/p/concurrentlinkedhashmap/source/browse/trunk/src/test/java/com/googlecode/concurrentlinkedhashmap/caches/LirsMap.java On Wed, 10 Jul 2019 at 20:16, Tristan Tarrant wrote: > > The bounding part was never part of Doug's code, but was written by us > > On Wed, 10 Jul 2019, 20:25 S

[infinispan-dev] BoundedConcurrentHashMap

Hi all, does anyone remember where BoundedConcurrentHashMap was copied from? we have a copy in Hibernate ORM; the comments state: - copied from Infinispan - original author Doug Lea but I don't see any similar implementation in JSR166, nor any reference to this classname on their archives: -

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

Hi Gunnar, if all you want is to invalidate Hibernate ORM's 2LC caches, Hibernate exposes a specific API to do just that. Sanne On Wed, 5 Dec 2018 at 14:30, Gunnar Morling wrote: > > Hey all, > > Thanks a lot for the quick replies! > > To give some background on what I was trying to do: my

Re: [infinispan-dev] Obtaining cache via CDI on WildFly

On Wed, 5 Dec 2018 at 11:16, Tristan Tarrant wrote: > > On 12/5/18 9:44 AM, Gunnar Morling wrote: > > Hey, > > > > I was trying to configure and inject an Infinispan cache through CDI, > > running on WildFly 14, using the Infinispan modules provided by the > > server. > > > > While I'm not sure

[infinispan-dev] Dependency hygiene: 2LC for Hibernate to depend on RxJava ?

Hi all, I noticed the latest versions of infinispan-core now depend on io.reactivex.rxjava2:rxjava aka RxJava. Would it be possible to make this an optional dependency, at least for those only looking for a simple JPA Cache? I tried to exclude it but that's not going to work, apparently many

Re: [infinispan-dev] Build broken

Dan fixed it via PR #6094 Thanks! On Tue, 26 Jun 2018 at 12:45, Sanne Grinovero wrote: > > Radim, Dan, your last commit 58aa3b2185 broke master. > > Please fix or revert ? > > Thanks ___ infinispan-dev mailing list infinispan-dev@lis

[infinispan-dev] Build broken

Radim, Dan, your last commit 58aa3b2185 broke master. Please fix or revert ? Thanks ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Upgrade to JTA 1.2 API?

; > On 26/06/18 10:08, Sanne Grinovero wrote: > > If I knew I would have opened a JIRA and sent a PR ;) > > > > The most important point IMO is that other projects such as WildFly and > > Hibernate are using the 1.2 version since a long time already so > > Infinispan

Re: [infinispan-dev] Upgrade to JTA 1.2 API?

issue. On Tue, 26 Jun 2018, 09:56 Galder Zamarreno, wrote: > Are the backwards compatible? Any gotchas we should be aware of? > > On Mon, Jun 25, 2018 at 10:07 PM Sanne Grinovero > wrote: > >> Would it be possible to upgrade >> - >> org.jboss.spec.ja

[infinispan-dev] Upgrade to JTA 1.2 API?

Would it be possible to upgrade - org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.1.Final to - org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:jar:1.0.1.Final ? Thanks! ___ infinispan-dev mailing list

Re: [infinispan-dev] Infinispan client/server architecture based on gRPC

t your PoC > looks like. > > - M > > > On Wed, 30 May 2018 at 08:19 Galder Zamarreno wrote: >> >> On Wed, May 30, 2018 at 5:00 PM Radim Vansa wrote: >>> >>> On 05/30/2018 02:53 PM, Sanne Grinovero wrote: >>> > On 30 May 2018 at 13:2

Re: [infinispan-dev] Infinispan client/server architecture based on gRPC

On 30 May 2018 at 13:26, Adrian Nistor wrote: > Yest, the client needs that hash but that does not necessarily mean it > has to compute it itself. > The hash should be applied to the storage format which might be > different from the format the client sees. So hash computation could be > done on

Re: [infinispan-dev] Infinispan client/server architecture based on gRPC

On 29 May 2018 at 13:45, Vittorio Rigamonti wrote: > Thanks Adrian, > > of course there's a marshalling work under the cover and that is reflected > into the generated code (specially the accessor methods generated from the > oneof clause). > > My opinion is that on the client side this could be

Re: [infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template

for it. > > Thanks again! > Seb Thanks Sebastian! > > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sa...@infinispan.org> wrote: >> >> Hi all, >> >> I've started to use the Infinispan Openshift Template and was browsing >> through the errors

[infinispan-dev] WFLYTX0013 in the Infinispan Openshift Template

Hi all, I've started to use the Infinispan Openshift Template and was browsing through the errors and warnings this produces. In particular I noticed "WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique." being produced by the transaction system. The

Re: [infinispan-dev] Testsuite: memory usage?

t;>>>> issues with running the core test suite. Unfortunately at the time CI and >>>>> everyone else seemed to not have any issues. I just ignored it because at >>>>> the time I didn't need to run core tests. But now that Sanne pointed this >>>

Re: [infinispan-dev] Hibernate Search integration modules for WildFly have been broken

postponed to 9.3+ and it might be much easier after migrating some Infinispan modules to feature packs as well. Thanks, Sanne On 7 February 2018 at 16:59, Sanne Grinovero <sa...@infinispan.org> wrote: > Hi all, > > I was going to give ISPN-8779 a shot but I'm finding

Re: [infinispan-dev] Testsuite: memory usage?

memory. > > I've yet to see an OOME in the core tests, locally or in CI. But I also > included -XX:+HeapDumpOnOutOfMemoryError in forkJvmArgs, so assuming there's > a new leak it should be easy to track down in the heap dump. > > Cheers > Dan > > > On Wed, Feb 14,

[infinispan-dev] Testsuite: memory usage?

Hey all, I'm having OOMs running the tests of infinispan-core. Initially I thought it was related to limits and security as that's the usual suspect, but no it's really just not enough memory :) Found that the root pom.xml sets a property to Xmx1G for surefire; I've been observing the growth

Re: [infinispan-dev] PersistentUUIDManagerImpl NPEs being logged when running the testsuite

:30, Sanne Grinovero <sa...@infinispan.org> wrote: > Hi all, > > I'm building master [1] and see such NPEs dumped on my terminal quite > often; I guess you all noticed already? I couldn't find a JIRA.. > > 16:24:03,083 FATAL > (transport-thread-StateTransferLinkFailuresT

[infinispan-dev] Hibernate Search integration modules for WildFly have been broken

Hi all, I was going to give ISPN-8779 a shot but I'm finding a mess. the root pom contains these twice (and inconsistent!): 5.8.1.Final [...] 5.8.0.Final the BOM cointains a copy of `version.hibernate.search` as well. I don't mind deleting duplicate properties, but we used to have clearly

Re: [infinispan-dev] Hot Rod secured by default

+1 To improve convenience, would be nice to also have some examples to configure credentials in some automated fashion; e.g. CLI scripts and an example of running them for a Maven integration test? Thanks, Sanne On 5 February 2018 at 11:02, Tristan Tarrant wrote: > Sorry

[infinispan-dev] PersistentUUIDManagerImpl NPEs being logged when running the testsuite

Hi all, I'm building master [1] and see such NPEs dumped on my terminal quite often; I guess you all noticed already? I couldn't find a JIRA.. 16:24:03,083 FATAL (transport-thread-StateTransferLinkFailuresTest[null, tx=false]-NodeN-p63985-t2) [PersistentUUIDManagerImpl] Cannot find mapping for

Re: [infinispan-dev] Fwd: [infinispan/infinispan] ISPN-8113 Querying via Rest endpoint (#5557)

+1 very interesting! On 9 November 2017 at 21:20, Galder Zamarreño wrote: > This is HUGE!! Kudos to Gustavo for the hard work you've done to get this > in!! > > Begin forwarded message: > > *From: *Adrian Nistor > *Subject: **Re:

Re: [infinispan-dev] Weekly IRC Meeting logs 2017-11-06

On 6 November 2017 at 19:23, Katia Aresti <kare...@redhat.com> wrote: > Totally agree with you Sanne, we need slack so this won’t happen again ! touché ! > > Le lun. 6 nov. 2017 à 20:10, Sanne Grinovero <sa...@infinispan.org> a écrit > : >> >> On 6

Re: [infinispan-dev] Weekly IRC Meeting logs 2017-11-06

On 6 November 2017 at 16:07, Dan Berindei wrote: > Hi everyone > > JBott wasn't available, so the meeting logs are available here: > > https://gist.github.com/danberindei/6d4d7e742eba41b0fb1bcba0ee735a8e Not a particularly critical detail, but it's quite hard to follow

Re: [infinispan-dev] Prepending internal cache names with org.infinispan instead of triple underscore

On 2 November 2017 at 22:20, Adrian Nistor wrote: > I like this proposal. +1 > On 11/02/2017 03:18 PM, Galder Zamarreño wrote: >> Hi all, >> >> I'm currently going through the JCache 1.1 proposed changes, and one that >> made me think is [1]. In particular: >> >>> Caches do

Re: [infinispan-dev] Replacing IRC

Sorry but I'm not going to use slack, I for one are planning to put my system resources to better use. On 18 Oct 2017 3:23 pm, "Sebastian Laskawiec" wrote: > +1 to Slack. All JUG communities I know are using it. It is also worth to > mention that Slack was also adopted by

Re: [infinispan-dev] Replacing IRC

Some of us do a lot of communications / planning related work on tablets & similar, and I assume that this trend will increase in the future. E.g. I regularly catch up on projects activity from the smartphone. May I suggest the "mobile client" to be considered an hard requirement? Changing

Re: [infinispan-dev] Adjusting memory settings in template

On 22 September 2017 at 16:58, Sebastian Laskawiec <slask...@redhat.com> wrote: > > > On Fri, Sep 22, 2017 at 5:05 PM Sanne Grinovero <sa...@infinispan.org> > wrote: >> >> On 22 September 2017 at 13:49, Sebastian Laskawiec <slask...@redhat.com> >>

Re: [infinispan-dev] Adjusting memory settings in template

On 22 September 2017 at 13:49, Sebastian Laskawiec wrote: > It's very tricky... > > Memory is adjusted automatically to the container size [1] (of course you > may override it by supplying Xmx or "-n" as parameters [2]). The safe limit > is roughly Xmx=Xms=50% of container

[infinispan-dev] Object instance reuse for reference data during Marshalling

Hi all, we discussed this need a while back [1] and there's great news: Galder created a demo showing how this might work on github: - https://github.com/galderz/shared-object-spaces In case you want to better understand what we're after I'd suggest to have a look: the code is trivial to read

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

On 11 August 2017 at 17:50, Galder Zamarreño <gal...@redhat.com> wrote: > > >> On 11 Aug 2017, at 16:30, Sanne Grinovero <sa...@infinispan.org> wrote: >> >> On 11 August 2017 at 14:14, Galder Zamarreño <gal...@redhat.com> wrote: >>> Hi, &g

Re: [infinispan-dev] Hot Rod client sending data to itself - ISPN-8186

On 11 August 2017 at 14:14, Galder Zamarreño wrote: > Hi, > > Re: https://issues.jboss.org/browse/ISPN-8186 > > I've been looking at TRACE logs and what seems to happen is that is that > sometimes, when the client needs to create a new Socket, it sends using the > same

Re: [infinispan-dev] tuned profiles for Infinispan ?

On 3 August 2017 at 18:11, Dan Berindei <dan.berin...@gmail.com> wrote: > > > On Thu, Aug 3, 2017 at 4:14 PM, Sanne Grinovero <sa...@infinispan.org> > wrote: >> >> >> >> On 19 Jul 2017 14:52, "Dan Berindei" <dan.berin...@gmail.

Re: [infinispan-dev] tuned profiles for Infinispan ?

read any documentation and do anything if > everything has already been provided by Infinispan authors). > > Nevertheless I think it might be worth to do a POC and host profiles in a > separate repository (to avoid user confusion). > > On Tue, Jul 11, 2017 at 6:49 PM Sanne Grinovero <

[infinispan-dev] NOVA: A Log-structured File system for Hybrid Volatile/Non-volatile Main Memories

This looks quite interesting! - http://lkml.iu.edu/hypermail/linux/kernel/1708.0/02224.html Not being just a traditional file system, I wonder if we could leverage some of its specific features like COW and the log structure to avoid such redundant operations from our side. For example Lucene's

Re: [infinispan-dev] Conflict Manager and Partition Handling Blog

On 1 August 2017 at 12:19, Ryan Emerson wrote: >> The option `REMOVE_ALL` seems sensible for the disposable Cache use >> case. One question though: if one partition has a defined value for a >> key, while the other partition has no value (null) for this same key, >> is it

Re: [infinispan-dev] Conflict Manager and Partition Handling Blog

Great job! I love to see this improved and being described in detail. +1 to add some practical examples, as I'm afraid we only notice limitations in features like this when thinking about specific use-cases. The option `REMOVE_ALL` seems sensible for the disposable Cache use case. One question

[infinispan-dev] tuned profiles for Infinispan ?

Hi all, tuned is a very nice utility to apply all kind of tuning options to a machine focusing on performance options. Of course it doesn't replace the tuning that an expert could provide for a specific system, but it gives people a quick an easy way to get to a reasonable starting point, which

Re: [infinispan-dev] Write-only commands

;full" previous version, definitely not meaning to suggest to break CQ and many other essential use cases. > > I'd remove these commands completely or possibly remove them just from > public API and keep them internal. > > Adrian > > > > On 06/27/2017 01:28 PM, Sann

Re: [infinispan-dev] Write-only commands

On 27 Jun 2017 10:13, "Radim Vansa" wrote: Hi, I am working on entry version history (again). In Como we've discussed that previous values are needed for (continuous) query and reliable listeners, Index based queries also require the previous value on a write - unless we

Re: [infinispan-dev] 9.1.0 endgame

On 21 June 2017 at 13:19, Tristan Tarrant wrote: > The release wrangler for 9.1.0.CR1 will be Will. > Will willl (haha !) perform the release on the 29th. This is a hard date. The date is hard but the month and year intentionally omitted :) > > Tristan > > On 6/19/17 12:22

Re: [infinispan-dev] Quick fix for ISPN-7710

On 15 June 2017 at 10:05, Adrian Nistor wrote: > Hi Galder, > > this fix is acceptable for now as it quickly enables users to use > CompatibilityProtoStreamMarshaller (provided by Infinispan), but in the > long run we would want users to be able to specify a custom marshaller

Re: [infinispan-dev] Hibernate Search v 5.8 and plans for beyond!

/2017/06/13/hibernate-search-5-8-0-Beta3/ Essentially our testsuite contains fully working examples. Thanks, Sanne > > Thanks, > Sebastian > > On Tue, Jun 13, 2017 at 8:34 PM Sanne Grinovero <sa...@infinispan.org> > wrote: > >> TLDR: the new Search SPI requires u

[infinispan-dev] Hibernate Search v 5.8 and plans for beyond!

TLDR: the new Search SPI requires using the "free form" types - but don't expect to be able to take advantage of it just yet. Hi all, we just released Hibernate Search 5.8.0.Beta3 and it's meant to be our last beta! Progress and pace are looking very good. The details of the release can be

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

On 9 June 2017 at 16:13, Alan Field wrote: > I really like this idea. It is similar to one of the solutions hinted at in > the Netty issue that Gustavo pointed at. [1] The suggestion there was to > replace their current uber jar that contains all of the shaded dependencies >

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

On 9 June 2017 at 08:29, Radim Vansa wrote: > Katia has recently pointed out some usability flaws, and we have > discussed a central point class that would allow you to explore the API: > instead of *knowing* about org.infinispan.query.Search or > org.infinispan.counters.

Re: [infinispan-dev] Why JCache embedded has core as provided dependency

On 7 June 2017 at 16:48, Galder Zamarreño wrote: > What has changed is that Stéphane has made a very good point which I had not > realised: > > Making core provided dependency means a JCache dependency user needs to add > core dependency on top of that, which reduces

Re: [infinispan-dev] Proposal for moving Hibernate 2l provider to Infinispan

A couple of comments inline: On 2 June 2017 at 13:45, Galder Zamarreño wrote: > I think it's going through, we've approved you in the past. > > Replies below: > >> On 31 May 2017, at 17:02, Steve Ebersole wrote: >> >> Just a heads up - FWIW I doubt my

[infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

Hi all, I've been running some benchmarks and for the fist time playing with Infinispan 9+, so please bear with me as I might shoot some dumb questions to the list in the following days. The need for TypeConverterDelegatingAdvancedCache to wrap most operations - especially "convertKeys" - is

Re: [infinispan-dev] Using load balancers for Infinispan in Kubernetes

Hi Sebastian, the "intelligent routing" of Hot Rod being one of - if not the main - reason to use Hot Rod, I wonder if we shouldn't rather suggest people to stick with HTTP (REST) in such architectures. Several people have suggested in the past the need to have an HTTP smart load balancer which

Re: [infinispan-dev] To Optional or not to Optional?

indings into >> > contributing guide [1]. >> > >> > Thanks, >> > Sebastian >> > >> > [1] >> > https://github.com/infinispan/infinispan/tree/ >> master/documentation/src/main/a

Re: [infinispan-dev] IRC chat: HB + I9

I would suggest option 4# : move the 2LC implementation to Infinispan. I already suggested this in the past, but to remind the main arguments I have: - neither repository is ideal, but having it here vs there is not just moving the problem as the two projects are different, have different

Re: [infinispan-dev] To Optional or not to Optional?

Hi Sebastian, sorry but I think you've been wasting time, I hope it was fun :) This is not the right methodology to "settle" the matter (unless you want Radim's eyes to get bloody..). Any change in such a complex system will only affect the performance metrics if you're actually addressing the

Re: [infinispan-dev] Deprecation of Index.LOCAL

+1 to deprecate it We might need some replacement for internal optimisations and building blocks, like you suggested it's at least useful for tests, but we shouldn't expose all this complexity. BTW these options have been introduced before myself and Adrian, so I guess nobody is around anymore

Re: [infinispan-dev] All jars must go?

some alternatives, but hey yes the APIs will have to change ;) - http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/ Thanks, Sanne > > [1]: https://github.com/infinispan/infinispan/blob/master/parent/pom.xml#L1614 > > Cheers > Dan > > > On Thu, May

Re: [infinispan-dev] All jars must go?

N.B. one problem many are not aware of is that - unlike with OSGi - the restriction in Jigsaw also applies to private packages, e.g. packages you're using within the jar but have no intention to "export" make public. So having this sorted out for OSGi doesn't mean that it will work fine with

Re: [infinispan-dev] Unwrapping exceptions

Personally as a user I'd expect to have a CacheException raised if and only if it's not caused by my own code. Imagine my own lambda is explicitly throwing an exception of a type of my choice, it would be nice to receive that error and not a different one. On 28 April 2017 at 11:38, Katia Aresti

Re: [infinispan-dev] Jenkins migration

Personally I've always used Jenkins and for that reason I didn't like Infinispan to use TeamCity - mainly as I'm not used to its UI - but I'll admit that its capability to focus on the test history, highlighting the first failure in time and its "stability" over time on a per-test focus rather

Re: [infinispan-dev] Jenkins migration

On 24 April 2017 at 13:08, Tristan Tarrant <ttarr...@redhat.com> wrote: > You mean exactly like the current CI is being handled? :-) > ​Cool, that other statement sounded like it could have misled you. > > On 24 Apr 2017 13:33, "Sanne Grinovero" <sa...@infinisp

Re: [infinispan-dev] Jenkins migration

On 24 April 2017 at 12:19, Sebastian Laskawiec wrote: > Hey! > > I uninstalled Blue Ocean plugin. I think it's worth to have another look > at it as soon as 1.1.0 is released [1]. > > I also plan to migrate 2 TeamCity Agents into Jenkins very shortly (in 30 > mins). > >

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

> problem naturally went away and Ryan removed it completely. > > On Mon, Apr 24, 2017 at 12:57 PM Sanne Grinovero <sa...@infinispan.org> > wrote: > >> Just to add, I see now that JBoss Logging is included as well. >> >> >> On 24 April 2017 at 11:43, S

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

Just to add, I see now that JBoss Logging is included as well. On 24 April 2017 at 11:43, Sanne Grinovero <sa...@infinispan.org> wrote: > Thanks Ryan. Beyond removing the relocation, I also doubt if it should > be included at all? I'm sincerely puzzled so I think we really need to

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

Thanks Ryan. Beyond removing the relocation, I also doubt if it should be included at all? I'm sincerely puzzled so I think we really need to hear from the others if this was intentional, or what the plan is. On 24 April 2017 at 11:40, Ryan Emerson wrote: > Previously slf4j

[infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

When inspecting the stuff included in the "shaded" jar infinispan-query-embedded, I even found a copy of SLF4J in there. It's being relocated to the package "/infinispan/org/slf4j/" Is that intentional? Does it even work in this way? I doubt it would be able to bind to the right appenders, or be

Re: [infinispan-dev] REST server, dealing with Serializable

On 24 April 2017 at 09:27, Sebastian Laskawiec wrote: > Hey Guys! > > I'm currently reworking REST interface and I'm scratching my head looking > how we deal with Serializable [1][2]. > > The scenario assumes that server knows that cache stores a Serializable > instance and

Re: [infinispan-dev] Infinispan Query API simplification

On 20 April 2017 at 21:31, Emmanuel Bernard wrote: > We did discuss something like > > cache.using(QueryableCache.class).createQuery("...").[build].list(); > > With some service locator system to have extensible and pluggable modules. > > We did discuss a potential problem

Re: [infinispan-dev] Infinispan Query API simplification

On 20 April 2017 at 13:56, Radim Vansa wrote: > That's completely opposite approach from the one outlined for > distributed counters and other "on-top" functionality (the same approach > was later suggested for conflict resolution manager, multimap and maybe > others). Why is

Re: [infinispan-dev] Infinispan Query API simplification

Looks good to me, at high level. This will have to focus on the capabilities of the non-indexed query engine though, as we won't be able to expose the more advanced capabilities over the DSL without introducing an hard dependency on Hibernate Search. Conversely, the method accepting an Ickle

Re: [infinispan-dev] Proto file for indexed and non-indexed use case?

Hi Galder, did you consider using a non-indexed cache for the second case? Thanks, Sanne On 3 April 2017 at 16:44, Galder Zamarreño wrote: > Hi Adrian, > > I had a question regarding proto files. I have a single domain of objects > that I want to use for two different use

Re: [infinispan-dev] Infinispan 9.0 Final

That looks awesome. Congratulations everyone! Now I'll start filing new issues from my wishlist for Hibernate OGM ;-) Thanks, Sanne On 31 March 2017 at 10:09, Tristan Tarrant wrote: > Dear all, > > we are proud to announce Infinispan 9.0 Final. > This release includes

Re: [infinispan-dev] Strategy to adopting Optional in APIs

I'm for "at discretion" and "avoid if not really needed" : not cool to allocate objects for no reason. On 30 Mar 2017 16:57, "Radim Vansa" wrote: > Hi, > > I was wondering what's the common attitude towards using Optional in > APIs, and what naming pattern should we use. As

Re: [infinispan-dev] Stream operations under lock

Hi Will, I'm confused about the premise; when you state " the Consumer is called while holding the lock for the given key and subsequently released after the Consumer operation completes." What are the transaction boundaries? I see two options, please correct me so I understand: A)

Re: [infinispan-dev] Branching proposal

You need to make sure you optimise for engineers coding stuff which works on master, not maintenance. Isn't it a bit naive to expect people to work on the "last maintained branch" ? Your proposal expect that each and every patch author: a) knows for sure it's not going to be backported further

[infinispan-dev] AffinityPartitioner: enable by default please?

Hi all, the explicit approach which we introduced with the AffinityPartitioner is extremely useful in most use cases for Embedded mode. I sent a PR on 18 Aug 2016 [1] to make this feature enabled by default so that people could benefit from it w/o needing to set it explicitly but it was not

Re: [infinispan-dev] Infinispan "mitosis"

ase. Thanks, Sanne > > Dan > > On Tue, Mar 14, 2017 at 3:08 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> Just throwing out an idea I just had while thinking of Hibernate OGM >> user needs for data migration. >> >> For people using databases &a

[infinispan-dev] Infinispan "mitosis"

Just throwing out an idea I just had while thinking of Hibernate OGM user needs for data migration. For people using databases & related frameworks, it's common to have a staging database which contains not just the staging "schema" but also data. When legally possible, it's often preferable to

Re: [infinispan-dev] Repeatable reads and WSC as default

Thanks! Sanne On 13 March 2017 at 11:50, Tristan Tarrant wrote: > Let's make it default. The 9.0 train definitely hasn't left the station yet. > > Tristan > > On 27/02/17 12:18, Radim Vansa wrote: >> Why is that JIRA closed? I was about to suggest that a complete JIRA >>

Re: [infinispan-dev] Repeatable reads and WSC as default

Since Infinispan 9 isn't final, and considering it's just flipping a switch for a default configuration, I don't think it's too late. This change would only "break" people who don't read the migration guides, and are running with the default configuration which is totally broken anyway so we

Re: [infinispan-dev] Auto-detection of appropriate key2StringMapperClass

On 9 March 2017 at 10:22, Dan Berindei <dan.berin...@gmail.com> wrote: > On Thu, Mar 9, 2017 at 11:48 AM, Sanne Grinovero <sa...@infinispan.org> wrote: >> Hi Dan! >> > > Hey Sanne :) > >> On 9 March 2017 at 09:38, Dan Berindei <dan.berin...@gmail

Re: [infinispan-dev] Auto-detection of appropriate key2StringMapperClass

can change between versions). It could even > do base64 encoding for databases that don't have a VARBINARY/BYTEA > equivalent. > > Cheers > Dan > > > On Wed, Mar 8, 2017 at 6:34 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> It seems I keep forgetting that the

[infinispan-dev] Auto-detection of appropriate key2StringMapperClass

It seems I keep forgetting that the "key2StringMapperClass" needs to be explicitly set when using the String based JDBC CacheStore, which I think is a quite popular store. http://infinispan.org/docs/dev/user_guide/user_guide.html#storing_the_index_in_a_database I think we could remove the need

[infinispan-dev] Concerns about the testsuite state

Hi all, I was mentioning on IRC today that I've seen many failures in the past hours, as I was trying to verify a simple PR. Tristan suggested to share some failures, so here are the outcomes of my first attempts to build Infinispan, each time restarting after a module would fail: Failed tests:

Re: [infinispan-dev] Classloader leaks?

> > On Thu, Feb 23, 2017 at 9:56 AM, Vojtech Juranek <vjura...@redhat.com> wrote: >> On středa 22. února 2017 23:31:55 CET Sanne Grinovero wrote: >>> Good point! You're right, I verified and all instances of e.g. the >>> jgroups jar were using the same FD, just

Re: [infinispan-dev] Classloader leaks?

it is set to 16384.. so I guess it could have attempted to grow further. Tomorrow I'll try with higher limits, to see if I'm running with barely enough for this testsuite or if I see it growing more. Still sounds like a leak though, as the increase is quite significant.. Thanks, Sanne > > -Denni

[infinispan-dev] Classloader leaks?

Hi all, our documentation suggest to raise the file limits to about 16K: http://infinispan.org/docs/stable/contributing/contributing.html#running_and_writing_tests I already have this setup since years, yet I've been noticing errors such as: "Caused by: java.io.IOException: Too many open files"

Re: [infinispan-dev] Major version cleaning

On 21 February 2017 at 16:16, Tristan Tarrant <ttarr...@redhat.com> wrote: > On 21/02/17 16:29, Sanne Grinovero wrote: >>> You haven't explained what "flush" means. Since you separate that from >>> atomicity/consistency, I assume that batches on non-tx cach

Re: [infinispan-dev] Major version cleaning

On 21 February 2017 at 14:52, Dan Berindei <dan.berin...@gmail.com> wrote: > On Tue, Feb 21, 2017 at 10:39 AM, Sanne Grinovero <sa...@infinispan.org> > wrote: >> On 21 February 2017 at 07:37, Dan Berindei <dan.berin...@gmail.com> wrote: >>> On Mon, Feb 2

Re: [infinispan-dev] Major version cleaning

On 21 February 2017 at 13:20, Radim Vansa <rva...@redhat.com> wrote: > On 02/21/2017 09:39 AM, Sanne Grinovero wrote: >> On 21 February 2017 at 07:37, Dan Berindei <dan.berin...@gmail.com> wrote: >>> On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero <sa...@in

Re: [infinispan-dev] JGroups 4.0 released

Congratulations! On 21 Feb 2017 12:21, "Bela Ban" wrote: > FYI: http://belaban.blogspot.ch/2017/02/jgroups-400final.html > > -- > Bela Ban, JGroups lead (http://www.jgroups.org) > > ___ > infinispan-dev mailing list >

Re: [infinispan-dev] Major version cleaning

On 21 February 2017 at 07:37, Dan Berindei <dan.berin...@gmail.com> wrote: > On Mon, Feb 20, 2017 at 8:02 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> -1 to batch removal >> >> Frankly I've always been extremely negative about the fact that >> batches

Re: [infinispan-dev] Major version cleaning

On 20 February 2017 at 20:11, Tristan Tarrant <ttarr...@redhat.com> wrote: > On 20/02/17 19:02, Sanne Grinovero wrote: >> -1 to batch removal >> >> Frankly I've always been extremely negative about the fact that >> batches are built on top of transactions. > &

Re: [infinispan-dev] Major version cleaning

-1 to batch removal Frankly I've always been extremely negative about the fact that batches are built on top of transactions. It's easy to find several iterations of rants of mine on this mailing list, especially fierce debates with Mircea. So I'd welcome a separation of these features. Yet,

Re: [infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC

Have fun with the rewriting! ;) More seriously, it might be worth to have a second module for Hibernate ORM 5.x to address Infinispan 9? At least in depth testing, stressing and performance aspect won't be left to the last minute integration step. Also, would it be worth to move such code to

Re: [infinispan-dev] Reverting ISPN-7426 because of hangs

I've sent a fix PR. Thanks for highlighting it! Sanne On 8 February 2017 at 11:32, Sanne Grinovero <sa...@hibernate.org> wrote: > I totally agree. This shouldn't have been merged in the first place, > but now that it's there and not that I know of the problem, let me > have a

Re: [infinispan-dev] Reverting ISPN-7426 because of hangs

; We need builds to run too. We can't have commits that bring the build to a > halt in such way that the build can't finish. > > Cheers, > -- > Galder Zamarreño > Infinispan, Red Hat > >> On 8 Feb 2017, at 12:18, Sanne Grinovero <sa...@infinispan.org> wrote: >>

Re: [infinispan-dev] Reverting ISPN-7426 because of hangs

Hi Galder, we need that upgrade. I didn't know of the OSGi problem, that seems trivial to fix.. next time just ask me? BTW I'd have noticed myself if only it was possible to run the Infinispan testsuite locally w/o it having so many failures.. Thanks, Sanne On 8 February 2017 at 10:25, Galder

Re: [infinispan-dev] Infinispan and change data capture

On 16 Dec 2016 12:39, "Tristan Tarrant" wrote: On 16/12/16 13:12, Emmanuel Bernard wrote: > >> On 16 Dec 2016, at 09:48, Tristan Tarrant wrote: >> >> On 16/12/16 09:34, Emmanuel Bernard wrote: Yes, the above design is what sprung to mind initially.

Re: [infinispan-dev] Infinispan and change data capture

be handled by the Debezium / > Kafka tail, not infinispan itself. > > Check my email on this tread from Dec 9th. > >> On 12 Dec 2016, at 16:13, Sanne Grinovero <sa...@infinispan.org> wrote: >> >> I'm reading many clever suggestions for various aspects of such

  1   2   3   4   5   6   7   8   9   10   >