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

Distributed Streams and the Cache Store implementations rely on rxjava2. I guess it could be made optional if we were ensure it was a local only cache without any stores. What does the simple JPA Cache in your example need? On Sun, Oct 7, 2018 at 7:01 PM Sanne Grinovero wrote: > Hi all, > > I

[infinispan-dev] Infinispan 9.2.5.Final is available

Dear all, We have a new, very minor release available, 9.2.5.Final. This release contains only a single fix for the Infinispan Server [1]. You can download it at the usual place [2]. [1] https://issues.jboss.org/browse/ISPN-9281 [2] http://infinispan.org/download/ Will

Re: [infinispan-dev] 9.2 EmbeddedCacheManager blocked at shutdown

On Fri, Apr 20, 2018 at 9:43 AM Thomas SEGISMONT wrote: > I tried our test suite on a slower machine (iMac from 2011). It passes > consistently there. > > On my laptop, I keep seeing this from time to time (in different tests): > > 2018-04-19T19:53:09.513 WARN

Re: [infinispan-dev] Passing client listener parameters programmatically

I personally have never been a fan of the whole annotation thing to configure your listener, unfortunately it just has been this way. If you are just proposing to adding a new addClientListener method that takes those arguments, I don't have a problem with it. void addClientListener(Object

Re: [infinispan-dev] Embedded mode: how-to get all caches started on all nodes?

On Thu, Mar 1, 2018 at 11:21 AM William Burns <mudokon...@gmail.com> wrote: > On Thu, Mar 1, 2018 at 11:14 AM Thomas SEGISMONT <tsegism...@gmail.com> > wrote: > >> 2018-03-01 16:36 GMT+01:00 Tristan Tarrant <ttarr...@redhat.com>: >> >>&

Re: [infinispan-dev] Embedded mode: how-to get all caches started on all nodes?

On Thu, Mar 1, 2018 at 11:14 AM Thomas SEGISMONT wrote: > 2018-03-01 16:36 GMT+01:00 Tristan Tarrant : > >> You need to use the brand new CacheAdmin API: >> >> >> http://infinispan.org/docs/stable/user_guide/user_guide.html#obtaining_caches > > > I'll

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

So I must admit I had noticed a while back that I was having some 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 out, by

[infinispan-dev] Exposure location of Minimum Node Required

Recently I have been working on [1]. Calculating this value is not a hard task. However as usual the hardest thing is where does this live and what is its name. In regards to its location I have a few places I was thinking: 1. CacheImpl/CacheManagerImpl - it would just be an exposed

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

+1 On Thu, Nov 2, 2017, 7:35 PM Adrian Nistor wrote: > I like this proposal. > > 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: > > > >>

Re: [infinispan-dev] 9.0.x branch not compiling

It was actually [1]. Will send a PR in just a few. [1] https://github.com/infinispan/infinispan/commit/905eb3551973db0590a336234e51aefeed62ec08#diff-3073de718ac371bd99728ce9e21557ce On Mon, Jul 3, 2017 at 5:40 AM Sebastian Laskawiec wrote: > Hey Will, Tristan, > > I think

Re: [infinispan-dev] Reactive Streams + RxJava

On Tue, Jun 20, 2017 at 3:59 AM Galder Zamarreño <gal...@redhat.com> wrote: > > -- > Galder Zamarreño > Infinispan, Red Hat > > > On 19 Jun 2017, at 15:25, William Burns <mudokon...@gmail.com> wrote: > > > > > > > > On Mon, Jun 19, 2017 at

Re: [infinispan-dev] Reactive Streams + RxJava

s/1.0.0 > > Emmanuel > > On 15 Jun 2017, at 23:20, William Burns <mudokon...@gmail.com> wrote: > > I was thinking more about [1] and I find that I was going to implement > basically reactive streams. What we have now in github is similar but it > uses a very crude

[infinispan-dev] Reactive Streams + RxJava

I was thinking more about [1] and I find that I was going to implement basically reactive streams. What we have now in github is similar but it uses a very crude method of blocking the thread to prevent back pressure. This can then cause severe issues as many users have found out when they don't

Re: [infinispan-dev] Moving functional API to core

On Tue, Jun 13, 2017, 3:54 AM Radim Vansa <rva...@redhat.com> wrote: > On 06/12/2017 04:52 PM, William Burns wrote: > > > > > > On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa <rva...@redhat.com > > <mailto:rva...@redhat.com>> wrote: > > > >

Re: [infinispan-dev] Moving functional API to core

On Sat, Jun 10, 2017 at 12:56 AM Radim Vansa wrote: > Hi guys, > > when the functional API has been outline, the interfaces were put into > infinispan-commons to make it possible to share these between remote > clients and embedded use case. However, it seems that reusing this

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

On Thu, Jun 1, 2017 at 7:11 AM Dan Berindei <dan.berin...@gmail.com> wrote: > On Wed, May 31, 2017 at 10:05 PM, William Burns <mudokon...@gmail.com> > wrote: > > Let me explain why it is there first :) This class was added for two main > > reasons: as a

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

elf. In fact these were mostly added for byte[] requirements. I just added in Compatibility support which required the same type of code. > > Some more comments inline: > > On 1 June 2017 at 11:12, Dan Berindei <dan.berin...@gmail.com> wrote: > > On Wed, May 31, 2017 at 10:05 PM,

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

Let me explain why it is there first :) This class was added for two main reasons: as a replacement for compatibility and for supporting equality of byte[] object. What this class does is at the user side is box the given arguments (eg. byte[] -> WrappedByteArray) then the cache only ever deals

Re: [infinispan-dev] Weekly IRC Meeting Logs 2017-05-29

Monday (yesterday) was a holiday for me. Last week I was mostly working on ISPN-7841 (lock streams). Thanks to Radim for review comments. I hope to have this all updated today. I also started looking into documentation for the new user guide section regarding executing code in the grid.

Re: [infinispan-dev] RemoteCache putAll javadoc outdated?

Yeah this should be updated. And to be honest since this is a public API I would say it probably shouldn't have any details like this on it as this is more implementation specific. We can get this fixed up though :) On Tue, Apr 25, 2017 at 7:41 AM Galder Zamarreno wrote: >

[infinispan-dev] Weekly IRC meeting

I will be unable to make it to the meeting today. Last week: ISPN-7479 Add Failover and Execution Policy to ClusterExecutor This has been completed and integrated. I also was looking at CI to find some stuff that could be fixed, I submitted ISPN-7743 DistributedStreamIteratorTest.testNode*

Re: [infinispan-dev] Streams & missing segments

Comments inline To be honest it might be easier to talk on IRC sometime since I am not sure the exact part you are trying to work on now. I am guessing you are reusing the ClusterStreamManager and LocalStreamManager parts and adapting as needed but I don't know for sure. On Mon, Apr 10, 2017 at

Re: [infinispan-dev] Native Infinispan Multimap support

d Spring support we can > make them super easy to use (by injecting newly created instances to the > users code: @Inject CacheMultimap myMap<String, String>). > > I also put some more comments below. Nice proposal Katia! > > On Tue, Apr 4, 2017 at 7:09 PM William Burns <m

Re: [infinispan-dev] Native Infinispan Multimap support

On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti wrote: > Hi all, > > As you probably know, Will and I are working on the vert-x infinispan > integration [1], where the primary goal is to make infinispan the default > cluster management of vert-x. (yeah!) > Vert-x needs support

Re: [infinispan-dev] Stream operations under lock

On Wed, Mar 29, 2017 at 4:05 AM Dan Berindei <dan.berin...@gmail.com> wrote: > On Tue, Mar 28, 2017 at 8:54 PM, William Burns <mudokon...@gmail.com> > wrote: > > > > > > On Tue, Mar 28, 2017 at 12:52 PM Dan Berindei <dan.berin...@gmail.com> > >

Re: [infinispan-dev] Stream operations under lock

On Tue, Mar 28, 2017 at 12:52 PM Dan Berindei <dan.berin...@gmail.com> wrote: > On Tue, Mar 28, 2017 at 6:44 PM, William Burns <mudokon...@gmail.com> > wrote: > > > > > > On Tue, Mar 28, 2017 at 11:24 AM Sanne Grinovero <sa...@infinispan.org> > >

Re: [infinispan-dev] Stream operations under lock

transaction and it doesn't really make sense in an optimistic transaction (since you are already at that node, you are already doing everything pessimistically). > > Thanks, > Sanne > > > > On 28 March 2017 at 14:49, William Burns <mudokon...@gmail.com> wrote: > > >

Re: [infinispan-dev] Stream operations under lock

hen you still have to iterate and check the entire data container/store. You could actually do both as well. So if you only want a subset of known keys where their values match a Predicate this can be done too. cache.lockedStream().filterKeys(keys).filter(predicate).forEach(); > > >

Re: [infinispan-dev] Stream operations under lock

On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <gal...@redhat.com> wrote: > > -- > Galder Zamarreño > Infinispan, Red Hat > > On 21 Mar 2017, at 18:50, William Burns <mudokon...@gmail.com> wrote: > > > > On Tue, Mar 21, 2017 at 1:42 PM William Burns <

Re: [infinispan-dev] Branching proposal

On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño wrote: > Why are we working in 9.1.x, 9.2.x and master in paralell? We normally > work on master and maybe one more maintenance branch. > > Except for occasional tricky backports (e.g. Radim's work) the rest has > been pretty

Re: [infinispan-dev] ConcurrentMap new methods implementation

On Thu, Mar 23, 2017 at 11:10 AM Dan Berindei wrote: > Ideally I'd like to properly support non-serializable lambdas, too, by > using conditional write operations and retrying if unsuccessful. If > that turns out to be too tricky, we could also support > non-serializable

Re: [infinispan-dev] Stream operations under lock

On Wed, Mar 22, 2017 at 5:51 AM Radim Vansa <rva...@redhat.com> wrote: > On 03/21/2017 06:50 PM, William Burns wrote: > > > > > > On Tue, Mar 21, 2017 at 1:42 PM William Burns <mudokon...@gmail.com > > <mailto:mudokon...@gmail.com>> wrote: > > &

[infinispan-dev] Deprecate collection methods on DataContainer interface

Recently while looking at the DataContainer interface and implementation it was noticed that the entrySet, values and keySet methods that return collections are very inconsistent. The big issue is whether these methods return expired entries or not and if they are backing or copies etc. It was

Re: [infinispan-dev] Stream operations under lock

On Tue, Mar 21, 2017 at 4:28 PM Tristan Tarrant <ttarr...@redhat.com> wrote: > > > On 21/03/17 16:37, William Burns wrote: > > Some users have expressed the need to have some sort of forEach > > operation that is performed where the Consumer is called while holding >

Re: [infinispan-dev] Stream operations under lock

On Tue, Mar 21, 2017 at 1:42 PM William Burns <mudokon...@gmail.com> wrote: > On Tue, Mar 21, 2017 at 12:53 PM Radim Vansa <rva...@redhat.com> wrote: > > On 03/21/2017 04:37 PM, William Burns wrote: > > Some users have expressed the need to have some so

Re: [infinispan-dev] Stream operations under lock

On Tue, Mar 21, 2017 at 12:53 PM Radim Vansa <rva...@redhat.com> wrote: > On 03/21/2017 04:37 PM, William Burns wrote: > > Some users have expressed the need to have some sort of forEach > > operation that is performed where the Consumer is called while holding > >

Re: [infinispan-dev] Stream operations under lock

some if we allowed other operations. > > Cheers > Dan > > > On Tue, Mar 21, 2017 at 5:37 PM, William Burns <mudokon...@gmail.com> > wrote: > > Some users have expressed the need to have some sort of forEach operation > > that is performed where the Consumer is ca

[infinispan-dev] Stream operations under lock

Some users have expressed the need to have some sort of forEach operation that is performed where the Consumer is called while holding the lock for the given key and subsequently released after the Consumer operation completes. Due to the nature of how streams work with retries and performing the

Re: [infinispan-dev] 9.0.0.CR4

Sounds good! Hopefully this will actually be the last CR :D On Mon, Mar 20, 2017 at 1:27 PM Tristan Tarrant wrote: > Guys, > > because of the amount of pending changes, I'd like to release 9.0.0.CR4 > on Wednesday 22nd and Final next week. > > Opinions ? > > Tristan > > --

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Name, new > > ConfigurationBuilder().build()) + getCache(cacheName). > > +1 > > Tristan > > >> R. > >> > >> [1] > >> > https://github.com/infinispan/infinispan/commit/73d99d37ebfb8af6b64df6a7579a2448deacbde7#diff-e2b618b97769a45ec42eb5910a8c21

Re: [infinispan-dev] Calling getCache with a template and defined configuration

as it is documented that a template is only applied if no cache configuration exists. What do you guys think? [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84 On Mon, Feb 27, 2017 at 10:09 AM William Burns <mudokon...@gmail.

Re: [infinispan-dev] Calling getCache with a template and defined configuration

instead. > Hrmm I like the idea of deprecating the overloads :) > > > > Cheers > Dan > > > On Mon, Feb 27, 2017 at 4:31 PM, William Burns <mudokon...@gmail.com> > wrote: > > When working on another project using Infinispan the code being used was &g

[infinispan-dev] Calling getCache with a template and defined configuration

When working on another project using Infinispan the code being used was a bit interesting and I don't think our template configuration handling was expecting it do so in such a way. Essentially the code defined a template for a distributed cache as well as some named caches. Then whenever a

Re: [infinispan-dev] Concerns about the testsuite state

ilures also look like they're caused by the > data container change. > > Dan > > On Thu, Feb 23, 2017 at 2:28 PM, William Burns <mudokon...@gmail.com> > wrote: > > All of the tests that failed with "The key was not evicted after 10 > inserts" > >

Re: [infinispan-dev] Concerns about the testsuite state

All of the tests that failed with "The key was not evicted after 10 inserts" should be fixed. The PR was integrated this morning [1]. That was half of your failures :-) The cluster listener one I have been taking with some guys about. Unfortunately I am not familiar with the others. [1]

Re: [infinispan-dev] Cluster Executor failover and execution policy

why I didn't think of that before. It felt awkward to me as well. Guess I was stuck on having the method have the name failover in it :) > > Vladimir > > > > On 2017-02-21 10:11 AM, William Burns wrote: > > As many of you are may or may not be aware the ClusterExecutor interface

[infinispan-dev] Cluster Executor failover and execution policy

As many of you are may or may not be aware the ClusterExecutor interface and implementation were introduced into Infinispan 8.2 [1]. This class is a new API that can be used to submit commands to other nodes in a way similar to DistributedExecutor does while also not being tied to a cache. The

Re: [infinispan-dev] GetKeyValueCommand NPE with CR1 in Hibernate 2LC - ISPN-7029

On Thu, Feb 16, 2017 at 8:51 AM Radim Vansa wrote: > On 02/16/2017 10:44 AM, Radim Vansa wrote: > > On 02/15/2017 06:07 PM, Galder Zamarreño wrote: > >> -- > >> Galder Zamarreño > >> Infinispan, Red Hat > >> > >>> On 15 Feb 2017, at 12:21, Radim Vansa

Re: [infinispan-dev] Data Container Changes Part 1

that should be mentioned here (and in the > javadoc/schema). > 5. Does bounded off-heap need extra locking? > 6. 36 bytes for "an additional address pointer" seems a bit excessive > :) Here too, I'd rather give an estimate of the overhead instead of > trying to explain exact

Re: [infinispan-dev] Data Container Changes Part 1

I tried to pair it down. I was thinking maybe if we thought there was interest I could go into more details in a future blog post. > > Cheers > Dan > > > > On Tue, Jan 24, 2017 at 12:21 AM, William Burns <mudokon...@gmail.com> > wrote: > > I just wanted to

Re: [infinispan-dev] Data Container Changes Part 1

I just wanted to let you all know that Part 2 of Data Container changes is now ready. Go ahead and check it at out at our new feature that we are very excited about at [2] ! [2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html On Mon, Dec 19, 2016 at 4:10 PM William Burns

[infinispan-dev] HotRod Server Test Decoder Perf Changes

I just wanted to take a quick sec to make people aware of a recent change to the HotRodTestingUtils class. If you are utilizing this class to create your hotrod server you may need to tweak how you are calling it [1]. What this change does is install an additional decoder which only sends 1 byte

Re: [infinispan-dev] State transfer-related terms

On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa wrote: > Hi, > > I've started (again) working on ISPN-5021 [1], and I'd like to get some > common agreement on few terms. So below I summarize my understanding (or > misunderstanding) of these, please state you opinion, thinking a

Re: [infinispan-dev] Data Container Changes Part 1

at 4:16 AM Radim Vansa <rva...@redhat.com> wrote: Regarding another use of Weighter in Caffeine: would it be possible to guarantee that an object with weight 0 (or negative one) is never evicted? R. On 12/19/2016 10:10 PM, William Burns wrote: > Check out some of the new changes to

[infinispan-dev] Data Container Changes Part 1

Check out some of the new changes to the Data Container in Infinispan 9.0. Beta 1 [1]. Part 2 will be probably after Holiday break. [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html ___ infinispan-dev mailing list

Re: [infinispan-dev] Off-Heap Storage Query

Storage. This will be great for JVM. > It is currently tied to our DataContainer API. It could be changed in the future though :) > > > > > > On Mon, Nov 14, 2016 at 1:29 PM, William Burns <mudokon...@gmail.com> > wrote: > > > > On Mon, Nov 14, 2016 at 12:27

Re: [infinispan-dev] Off-Heap Storage Query

On Mon, Nov 14, 2016 at 12:27 PM Alan Kash wrote: > Hi, > > Is there any architecture document of Off-Heap storage architecture. Do we > have an ETA for this feature. > I am planning on creating a PR for this week assuming everything goes well. The required PRs to be

Re: [infinispan-dev] Data Container configuration changes

Since I have had some time to think it over I like Pedro's layout, unless someone has a strong objection. Responses inline. On Mon, Oct 31, 2016 at 4:51 AM Radim Vansa <rva...@redhat.com> wrote: > On 10/27/2016 05:26 PM, William Burns wrote: > > > > > > On Thu, Oc

Re: [infinispan-dev] Data Container configuration changes

On Thu, Oct 27, 2016 at 9:56 AM Pedro Ruivo <pe...@infinispan.org> wrote: > > > On 27-10-2016 14:20, William Burns wrote: > > > > > > On Thu, Oct 27, 2016 at 4:56 AM Pedro Ruivo <pe...@infinispan.org > > <mailto:pe...@infinispan.org>> wrote: >

Re: [infinispan-dev] Data Container configuration changes

On Thu, Oct 27, 2016 at 9:40 AM Tristan Tarrant <ttarr...@redhat.com> wrote: > On 27/10/16 00:06, William Burns wrote: > > The reason it is a subelement instead of a property is because off-heap > > will most likely require some additional configuration to tell how many

Re: [infinispan-dev] Data Container configuration changes

On Thu, Oct 27, 2016 at 4:56 AM Pedro Ruivo <pe...@infinispan.org> wrote: > > > On 26-10-2016 23:06, William Burns wrote: > > I have been working on adding in off heap support for a given cache. I > > wanted to check in and let you all know what I was thinkin

Re: [infinispan-dev] Compatiibility 2.0 dump

On Mon, Jul 25, 2016 at 10:03 AM Galder Zamarreño wrote: > > > On 22 Jun 2016, at 17:44, Radim Vansa wrote: > > > > I've spotted things like 'decorating cache' in the wiki page. I though > > that the core architecture in Infinispan, modifying the behavior >

Re: [infinispan-dev] Changing default Hot Rod client max retries

On Wed, Jun 1, 2016 at 8:35 AM Dan Berindei wrote: > I'd also like to see an option for the total time to wait, instead of > having to worry about two (or more) different settings. > Only 1 config sounds good to me. I admit I am more used to total time to wait rather

[infinispan-dev] Singleton Cache Stores with Shared Cache Stores

Recently there was a start of a discussion regarding singleton cache stores and how they behave. Interestingly according to our documentation [1] and verification code [2] a singleton store cannot be used with a shared cache store. This makes no sense to me as this means you would have a single

Re: [infinispan-dev] Potential for context object for serial/deserial in marshalling rework

On Thu, Apr 21, 2016 at 6:56 AM Sanne Grinovero wrote: > Hey Galder, > these "scopes" you mention sound cool, but I'm afraid you'd end up > designing a user friendly API more than allowing the level of > performance optimisations we need. > > If we pass a "context" map, or

Re: [infinispan-dev] Potential for context object for serial/deserial in marshalling rework

On Thu, Apr 21, 2016 at 4:35 AM Galder Zamarreño wrote: > For example, I'd like to get some clarification on the scope of the > context object: > > @Will, will the solution you provided in [2] deal with multiple JGroups > marshalling request callbacks? Or is it only designed

Re: [infinispan-dev] Should Tree module be deprecated?

I think we should at least deprecate it for 9.0, if not totally remove it (although I understand we probably can't remove it yet) TreeCache seems to pop up a lot with people complaining about it. - Will On Tue, Mar 29, 2016 at 3:48 AM Galder Zamarreño wrote: > Re: >

Re: [infinispan-dev] Distributed Executor remote cancellation

16 18:19, Sanne Grinovero wrote: > > The term "Interruption" might have been too specific, but being able > > to cancel a task seems essential to me. > > > > On 30 March 2016 at 17:04, William Burns <mudokon...@gmail.com> wrote: > &g

[infinispan-dev] Distributed Executor remote cancellation

Recently we have been moving a lot of our methods that return Future [1] to CompletableFuture [2]. Unfortunately the latter, CompletableFuture, doesn't allow for cancellation of the future, since there is no thread tied to it. So I am proposing that our DistributedExecutorService [3] no longer

Re: [infinispan-dev] Lambda Serialization

On Thu, Mar 3, 2016 at 10:40 AM William Burns <mudokon...@gmail.com> wrote: > On Thu, Mar 3, 2016 at 10:26 AM Sanne Grinovero <sa...@infinispan.org> > wrote: > >> On 3 March 2016 at 15:19, William Burns <mudokon...@gmail.com> wrote: >> > I now have a wor

Re: [infinispan-dev] Lambda Serialization

On Thu, Mar 3, 2016 at 10:26 AM Sanne Grinovero <sa...@infinispan.org> wrote: > On 3 March 2016 at 15:19, William Burns <mudokon...@gmail.com> wrote: > > I now have a working branch that is using this for the new CacheStream > > interface [1]. > > > > Wi

Re: [infinispan-dev] Lambda Serialization

96422ec#diff-170c50a8f618af028f238109f0f1392a [3] https://github.com/wburns/infinispan/blob/ISPN-6272/core/src/main/java/org/infinispan/util/SerializableFunction.java [4] https://gist.github.com/wburns/dffe4f7543f68215f74b On Wed, Feb 17, 2016 at 8:39 AM William Burns <mudokon...@gmail.com> wrote: >

Re: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now!

Awesome, great work! Pretty slick we even support listeners already :) - Will On Thu, Feb 18, 2016 at 6:04 AM Galder Zamarreño wrote: > Hi, > > Following on Tristan's anouncement, we've also released Infinispan > Javascript client version 0.1.0. You can read all about it

[infinispan-dev] Fwd: Lambda Serialization

Sent that message a bit too soon. Fixed a typo and added 9.0 version for stream methods. -- Forwarded message - From: William Burns <mudokon...@gmail.com> Date: Tue, Feb 9, 2016 at 3:21 PM Subject: Re: Lambda Serialization To: infinispan -Dev List <infinispan-dev@lists.

[infinispan-dev] Lambda Serialization

I wanted to propose a pretty simple way of making the lambdas serializable by default that I stumbled upon while working on another issue. I noticed that in the method resolution of the compiler it does some nice things [1]. To be more specific when you have 2 methods with the same name but vary

Re: [infinispan-dev] Lambda Serialization

interfaces. This however would be used with [1], which is targeted for 7.2, to allow for much easier way to provide Callable/Runnable instances through lambdas without having to do the ugly casting. [1] https://issues.jboss.org/browse/ISPN-6074 On Tue, Feb 9, 2016 at 11:36 AM William Burns

Re: [infinispan-dev] jdk8backported package

Unfortunately this isn't really possible to remove these classes. They have additional changes over and above the jdk8 classes. We could move it into a different package though if we wanted to. To be honest the only reason this is still really needed is for the BoundedConcurrentHashMapV8. I

Re: [infinispan-dev] jdk8backported package

On Mon, Jan 25, 2016 at 9:24 AM Sanne Grinovero <sa...@infinispan.org> wrote: > On 25 January 2016 at 14:15, William Burns <mudokon...@gmail.com> wrote: > > Unfortunately this isn't really possible to remove these classes. They > have > > additional changes over a

Re: [infinispan-dev] jdk8backported package

ction stuff, since there is no pluggable way to do this with the JVM classes. > > On Mon, Jan 25, 2016 at 3:15 PM, William Burns <mudokon...@gmail.com> > wrote: > >> Unfortunately this isn't really possible to remove these classes. They >> have additional changes

Re: [infinispan-dev] Consolidating temporary per-key data

I am not sure there is an easy way to consolidate these into a single map, since some of these are written to on reads, some on writes and sometimes conditionally written to. And then as Dan said they are cleaned up at different times possibly. We could do something like states (based on which

Re: [infinispan-dev] Consolidating temporary per-key data

Sanne Grinovero <sa...@infinispan.org> wrote: > Wouldn't it be an interesting compromise to make sure we calculate > things like the key's hash only once? > > On 30 November 2015 at 21:54, William Burns <mudokon...@gmail.com> wrote: > > I am not sure there

[infinispan-dev] Infinispan 8.1.0.Beta1 is out!

Hello everyone, The first beta is now available of Infinispan 8.1.0. The new management console has progressed even further. We have a few screenshots to highlight this. You can see them at [1]. We also have fixed quite a few bugs and added some minor performance improvements for various

Re: [infinispan-dev] Cache entry creation and modification events

I also like #3. However I wonder if we want to expand it to include cache removal/expiration in this new event as well. This would simplify a user listening for data being changed in only a given listener and it could be clustered. - Will On Thu, Oct 8, 2015 at 6:38 AM Galder Zamarreño

Re: [infinispan-dev] TaskManager

Since I can't comment on the wiki page, will send it here. 1. I am not sure what our other REST operations do, but imo we shouldn't be using a GET to run a script. A GET to me should be idempotent, in our case the script can modify underlying resources and return different results each time. 2.

Re: [infinispan-dev] Hibernate ORM 5.0.0.CR4 not working so well with Infinispan 8.0.0.Beta2...

needed to run? And since we know to watch out for the binary compatibility we can make sure it stays that way for the 8.0 Final release. Radim [1] https://github.com/hibernate/hibernate-orm/pull/1045 On 08/06/2015 04:17 PM, William Burns wrote: On Thu, Aug 6, 2015 at 4:42 AM Tristan

Re: [infinispan-dev] Hibernate ORM 5.0.0.CR4 not working so well with Infinispan 8.0.0.Beta2...

On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant ttarr...@redhat.com wrote: On 06/08/2015 10:30, Sanne Grinovero wrote: On 6 August 2015 at 03:01, William Burns mudokon...@gmail.com wrote: It seems ORM was compiled with a version earlier than Beta1 but then ran with Beta2? The keySet

Re: [infinispan-dev] Hibernate ORM 5.0.0.CR4 not working so well with Infinispan 8.0.0.Beta2...

It seems ORM was compiled with a version earlier than Beta1 but then ran with Beta2? The keySet method was changed to return a subclass of CloseableIteratorSet with Beta2 to support distributed streams [1]. [1]

[infinispan-dev] Fwd: Strict Expiration

/infinispan/blob/master/core/src/main/java/org/infinispan/persistence/spi/AdvancedCacheWriter.java#L29 [2] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/persistence/spi/CacheLoader.java#L34 -- Forwarded message - From: William Burns mudokon

Re: [infinispan-dev] Fwd: Strict Expiration

. On 07/23/2015 02:37 PM, William Burns wrote: I actually found another hiccup with cache stores. It seems currently we only allow for a callback when an entry is expired from a cache store when using the reaper thread [1]. However we don't allow for such a callback on a read which finds

Re: [infinispan-dev] Strict Expiration

owner and some nodes have the old value and someone registers an expiration listener. I am thinking I should only raise the event if the primary owner still has the value. Dan On Tue, Jul 21, 2015 at 5:25 PM, William Burns mudokon...@gmail.com wrote: So I wanted to sum up what it looks like

Re: [infinispan-dev] Strict Expiration

needs to handle that internally. Radim [1] https://hibernate.atlassian.net/browse/HHH-6219 On 07/14/2015 05:45 PM, Dennis Reed wrote: On 07/14/2015 11:08 AM, Radim Vansa wrote: On 07/14/2015 04:19 PM, William Burns wrote: On Tue, Jul 14, 2015 at 9:37 AM William Burns mudokon...@gmail.com

Re: [infinispan-dev] Strict Expiration

compatibility - ensure that we document this properly Tristan On 13/07/2015 18:41, Sanne Grinovero wrote: +1 You had me convinced at the first line, although A lot of code can now be removed and made simpler makes it look extremely nice. On 13 Jul 2015 18:14, William Burns mudokon

Re: [infinispan-dev] Strict Expiration

On Tue, Jul 14, 2015 at 9:37 AM William Burns mudokon...@gmail.com wrote: On Tue, Jul 14, 2015 at 4:41 AM Dan Berindei dan.berin...@gmail.com wrote: Processing expiration only on the reaper thread sounds nice, but I have one reservation: processing 1 million entries to see that 1 of them

[infinispan-dev] Strict Expiration

This is a necro of [1]. With Infinispan 8.0 we are adding in clustered expiration. That includes an expiration event raised that is clustered as well. Unfortunately expiration events currently occur multiple times (if numOwners 1) at different times across nodes in a cluster. This makes

Re: [infinispan-dev] Distributed Streams

On Thu, Jul 9, 2015 at 12:28 PM Dan Berindei dan.berin...@gmail.com wrote: On Thu, Jul 9, 2015 at 3:49 PM, William Burns mudokon...@gmail.com wrote: On Thu, Jul 9, 2015 at 5:11 AM Dan Berindei dan.berin...@gmail.com wrote: Hi Will After the discussion we started in Galder's PR's

Re: [infinispan-dev] Distributed Streams

On Thu, Jul 9, 2015 at 11:33 AM Radim Vansa rva...@redhat.com wrote: On 07/09/2015 02:49 PM, William Burns wrote: On Thu, Jul 9, 2015 at 5:11 AM Dan Berindei dan.berin...@gmail.com mailto:dan.berin...@gmail.com wrote: Hi Will After the discussion we started in Galder's

Re: [infinispan-dev] Distributed Streams

slower, but it should hopefully reduce some memory usage :P Cheers Dan [1] https://github.com/infinispan/infinispan/pull/3571#discussion-diff-34033399R22 On Wed, May 27, 2015 at 9:52 PM, William Burns mudokon...@gmail.com wrote: Hello everyone, I wanted to let you know I wrote up

Re: [infinispan-dev] Threads, Quasar, Fibers and DSLs

On Tue, Jun 16, 2015 at 8:23 AM Sanne Grinovero sa...@infinispan.org wrote: Hi all, we recently discussed about the problem of modelling locks as Java locks, and blocking our actual threads - or have to delegate to internal large threadpools - to model the parking of a thread which is

Re: [infinispan-dev] State Transfer Invalidation Caches

but it's not relaxing the consistency and transactional guarantees which we normally provide with other cache modes. We could of course argue if it could be useful to provide a relaxed consistency mode, but I'd really not drop the stronger model. -- Sanne On 17 June 2015 at 19:32, William

[infinispan-dev] State Transfer Invalidation Caches

Recently [1] was found. The underlying cause is that now initial state transfer is enabled by default including invalidation caches. When thinking about this I didn't even realize that we utilize a Replicated consistent hash for invalidation mode. This all strikes me as just wrong. To me an

  1   2   >