Re: [infinispan-dev] Optional in listener events

On Wed, Aug 24, 2016 at 4:14 PM, Adrian Nistor wrote: > I remember there was some discussion to refactor listeners to drop the > concept of pre-events and have the previous value available in the > post-event (where applicable). I do not remember what decision was made > about

Re: [infinispan-dev] Fine grained maps

On Tue, Sep 27, 2016 at 10:28 AM, Radim Vansa <rva...@redhat.com> wrote: > To Pedro: I have figured out that it shouldn't work rather > theoretically, so I haven't crashed into ISPN-2729. > > On 09/26/2016 10:51 PM, Dan Berindei wrote: >> On Mon, Sep 26, 2016 at 10

Re: [infinispan-dev] Fine grained maps

On Tue, Sep 27, 2016 at 6:15 PM, Radim Vansa <rva...@redhat.com> wrote: > On 09/27/2016 04:47 PM, Dan Berindei wrote: >> On Tue, Sep 27, 2016 at 10:28 AM, Radim Vansa <rva...@redhat.com> wrote: >>> To Pedro: I have figured out that it shouldn't work rather >>&

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

t: >> https://github.com/slaskawi/jboss-logging-perf-test? >> >> >> >> On Mon, Oct 3, 2016 at 2:40 PM, Dan Berindei <dan.berin...@gmail.com> >> wrote: >>> >>> Hi Sebastian >>> >>> I modified your benchmark so tha

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

laces is probably >> not an option. >> >> @David - Let me run a test with JBoss Log Manager and get back to you with >> some results. But if Dan is right, and the problem is with enum mapping, I >> will get similar results. >> >> Thanks >> Sebasti

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

On Fri, Sep 30, 2016 at 10:15 PM, David M. Lloyd wrote: > The performance problem that this trick is meant to resolve is really a > problem in the logging backend. It *should* be faster inside of > WildFly, where JBoss LogManager is used, because that project just >

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

oing to open a BZ. > > -Dennis > > > On 09/30/2016 08:23 AM, Sanne Grinovero wrote: >> this discussion appears on this mailing list approximately every 2 years :) >> >> On 30 September 2016 at 13:41, Dan Berindei <dan.berin...@gmail.com> wrote: >>> I should str

Re: [infinispan-dev] Func API in tx cache

In theory something like this should work, resuming the transaction after each asynchronous operation: https://paste.fedoraproject.org/461451/77496416/raw/ I'm not sure about the usability, or performance... The TransactionManager API doesn't allow asynchronous commit(), so one might as well

Re: [infinispan-dev] Triangle and ISPN-3918

On Mon, Nov 14, 2016 at 4:49 PM, Pedro Ruivo wrote: > > > On 14-11-2016 14:26, Radim Vansa wrote: >> Hi, >> >> I was thinking about ISPN-3918 [1] and I've realized that while this >> happens in current implementation only rarely during state transfer, >> with Triangle v4

Re: [infinispan-dev] Names, names, names...

On Mon, Oct 17, 2016 at 2:16 PM, Sanne Grinovero wrote: > On 17 October 2016 at 09:35, Radim Vansa wrote: >> On 10/17/2016 09:07 AM, Tristan Tarrant wrote: >>> Hi all, >>> >>> something trivial and fun for a Monday morning. >>> >>> I've just issued a PR

Re: [infinispan-dev] TestingUtil.shortTimeoutMillis

inispan.org/viewLog.html?buildId=53604=bt9 > > On 03/27/2017 11:25 AM, Dan Berindei wrote: >> Radim, are you seeing this in the regular builds too, or just in the >> TRACE build? >> >> Dan >> >> >> On Mon, Mar 27, 2017 at 11:59 AM, Sebastian Laskawiec &g

Re: [infinispan-dev] Stream operations under lock

transaction (since you are already at that node, you are already > doing everything pessimistically). > Even local caches can use optimistic locking :) >> >> >> Thanks, >> Sanne >> >> >> >> On 28 March 2017 at 14:49, William Burns <mudokon...

Re: [infinispan-dev] TestingUtil.shortTimeoutMillis

Radim, are you seeing this in the regular builds too, or just in the TRACE build? Dan On Mon, Mar 27, 2017 at 11:59 AM, Sebastian Laskawiec wrote: > Sounds good... > > Sadly our build infrastructure is not very fast... > > On Mon, Mar 27, 2017 at 10:58 AM Radim Vansa

Re: [infinispan-dev] Deprecate collection methods on DataContainer interface

You have my vote :) Dan On Thu, Mar 23, 2017 at 3:26 PM, William Burns wrote: > 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

Re: [infinispan-dev] Stream operations under lock

On Wed, Mar 22, 2017 at 11:51 AM, Radim Vansa wrote: > On 03/21/2017 06:50 PM, William Burns wrote: >> >> >> On Tue, Mar 21, 2017 at 1:42 PM William Burns > > wrote: >> >> On Tue, Mar 21, 2017 at 12:53 PM Radim Vansa

Re: [infinispan-dev] Stream operations under lock

On Wed, Mar 29, 2017 at 4:24 PM, William Burns <mudokon...@gmail.com> wrote: > > > 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: >&g

Re: [infinispan-dev] Stream operations under lock

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> > wrote: >> >> On Tue, Mar 28, 2017 at 6:44 PM, William Burns <mudokon...@gmail.com> >> wrote:

Re: [infinispan-dev] Branching proposal

On Mon, Mar 27, 2017 at 2:51 PM, Sebastian Laskawiec wrote: > > > On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero > wrote: >> >> You need to make sure you optimise for engineers coding stuff which >> works on master, not maintenance. > > > Well it

Re: [infinispan-dev] Branching proposal

I use something like this to check what tags contain a particular fix: git tag --contains $(git log --grep -1 --format="%h" master) True, it's a bit longer, but it stays in the bash/zsh history :) Cheers Dan On Mon, Mar 27, 2017 at 1:33 PM, Radim Vansa wrote: > If you

Re: [infinispan-dev] 9.0.0.CR4

+1 On Mon, Mar 20, 2017 at 8:16 PM, William Burns wrote: > 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

[infinispan-dev] Weekly IRC meeting logs 2017-04-03

Hi all I forgot to send out the meeting logs for yesterday's meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-04-03-14.01.html Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

Re: [infinispan-dev] Infinispan Query API simplification

On Thu, Apr 20, 2017 at 3:56 PM, 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).

Re: [infinispan-dev] Infinispan Query API simplification

On Thu, Apr 20, 2017 at 5:06 PM, Tristan Tarrant <ttarr...@redhat.com> wrote: > On 20/04/2017 15:34, Dan Berindei wrote: >>> >>> How big is the DSL API surface (which will be brought into commons)? >> >> >> -1 from me to add anything in commons, I do

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

Every store can have its own Key2StringMapper, so I really don't think service discovery is appropriate here. My favourite solution would be to have a default Key2StringMapper implementation that uses Java serialization (not our internal marshalling, because that can change between versions). It

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

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.com> wrote: >> Every store can have its own Key2StringMapper, so I really don't think >> serv

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

On Thu, Mar 9, 2017 at 1:09 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > 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! >

Re: [infinispan-dev] Cache Store Marshalling

+100 to use a separate marshaller for user types, but I think the persistence configuration is the wrong place for it. Users shouldn't have to implement an AdvancedExternalizer for efficient replication between nodes if they already have a marshaller that's efficient enough for use in a store. I

Re: [infinispan-dev] Infinispan "mitosis"

Yes, rolling upgrades should be even better, because for x-site you need the source cluster to have a backup site configured (but not enabled), and adding that to a running cluster may require a one-by-one restart of all the nodes. Dan On Tue, Mar 14, 2017 at 4:10 PM, Gustavo Fernandes

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

gt; >> 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.com >>

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

Maybe yes, maybe not... in my experience escape analysis is very fickle, e.g. it's very easy for a method to become big enough after inlining that escape analysis is not performed at all. Dan On Fri, Mar 31, 2017 at 10:59 AM, Tristan Tarrant wrote: > I was about to say the

Re: [infinispan-dev] Stream operations under lock

I'm leaning towards option 1. Are you thinking about also allowing the consumer to modify the entry, like JCache's EntryProcessors? For a consumer that can only modify the current entry, we could even "emulate" locking in an optimistic cache by catching the WriteSkewException and running the

Re: [infinispan-dev] Jenkins migration

04/23/2017 07:14 PM, Adrian Nistor wrote: >> I also do not see much value in the current state of Blue Ocean. >> Better stick with the default ui. >> >> On 04/21/2017 06:11 PM, Dan Berindei wrote: >>> Looks like the invalid "control characters from U+ throug

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

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.com> wrote: > > Can't we just copy a profile from Hibernate or WildFly? > > > I'm not aware of such profiles.

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

Can't we just copy a profile from Hibernate or WildFly? Dan On Wed, Jul 19, 2017 at 2:40 PM, Emmanuel Bernard wrote: > I don’t think it discourages, the people you pention would simply use the > “default” profile. At least with a list of profiles, the idea of tuning >

Re: [infinispan-dev] Write-only commands

On Thu, Jun 29, 2017 at 4:51 PM, Radim Vansa <rva...@redhat.com> wrote: > On 06/29/2017 02:36 PM, Dan Berindei wrote: >> On Thu, Jun 29, 2017 at 2:19 PM, Radim Vansa <rva...@redhat.com> wrote: >>> On 06/29/2017 11:16 AM, Dan Berindei wrote: >>>> On Thu,

Re: [infinispan-dev] Write-only commands

On Tue, Jun 27, 2017 at 2:43 PM, Adrian Nistor wrote: > I've said this in a previous thread on this same issue, I will repeat myself > as many times as needed. > > Continuous queries require the previous value itself, not just knowledge of > the type of the previous value.

Re: [infinispan-dev] Write-only commands

On Wed, Jun 28, 2017 at 5:25 PM, Radim Vansa <rva...@redhat.com> wrote: > On 06/28/2017 01:17 PM, Radim Vansa wrote: >> On 06/28/2017 10:40 AM, Dan Berindei wrote: >>> On Wed, Jun 28, 2017 at 10:17 AM, Radim Vansa <rva...@redhat.com> wrote: >>>>

Re: [infinispan-dev] Write-only commands

On Thu, Jun 29, 2017 at 11:53 AM, Radim Vansa <rva...@redhat.com> wrote: > On 06/28/2017 04:20 PM, Dan Berindei wrote: >> On Wed, Jun 28, 2017 at 2:17 PM, Radim Vansa <rva...@redhat.com> wrote: >>> On 06/28/2017 10:40 AM, Dan Berindei wrote: >>>> On Wed,

Re: [infinispan-dev] Write-only commands

On Thu, Jun 29, 2017 at 2:19 PM, Radim Vansa <rva...@redhat.com> wrote: > On 06/29/2017 11:16 AM, Dan Berindei wrote: >> On Thu, Jun 29, 2017 at 11:53 AM, Radim Vansa <rva...@redhat.com> wrote: >>> On 06/28/2017 04:20 PM, Dan Berindei wrote: >>>> On Wed,

Re: [infinispan-dev] Write-only commands

On Wed, Jun 28, 2017 at 2:17 PM, Radim Vansa <rva...@redhat.com> wrote: > On 06/28/2017 10:40 AM, Dan Berindei wrote: >> On Wed, Jun 28, 2017 at 10:17 AM, Radim Vansa <rva...@redhat.com> wrote: >>> On 06/27/2017 03:54 PM, Dan Berindei wrote: >>>> On T

Re: [infinispan-dev] Jenkins migration

Looks like the invalid "control characters from U+ through U+001F" are the ANSI escape codes used by WildFly to color output. So we might be able to work around this by disabling the color output in WildFly in our integration tests. OTOH I'm fine with removing the Blue Ocean plugin for now,

Re: [infinispan-dev] Jenkins migration

dismissed in the first place? >> > > Once BlueOcean was installed (I think by Dan or Gustavo), it replaced the > default UI without asking. > > >> >> R. >> >> On 04/23/2017 07:14 PM, Adrian Nistor wrote: >> > I also do not see much value in the curre

[infinispan-dev] Weekly IRC meeting logs 2017-06-26

Hi everyone Here are the logs of today's meeting on #infinispan: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-06-26-14.03.html Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

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

I wouldn't say I'm an extreme naysayer, but I do have 2 issues with Optional: 1. Performance becomes harder to quantify: the allocations may or may not be eliminated, and a change in one part of the code may change how allocations are eliminated in a completely different part of the code. 2. My

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

On Wed, May 31, 2017 at 10:05 PM, William Burns wrote: > 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

Re: [infinispan-dev] Important feedback for transcoding work - Re: Quick fix for ISPN-7710

On Fri, Jun 16, 2017 at 1:07 PM, Galder Zamarreño wrote: > > -- > Galder Zamarreño > Infinispan, Red Hat > >> On 15 Jun 2017, at 15:25, Adrian Nistor wrote: >> >> Galder, I've seen AddProtobufTask in March or April when you mentioned this >> issue on the

Re: [infinispan-dev] HotRod client TCK

On Mon, May 8, 2017 at 2:32 PM, Galder Zamarreño wrote: > Btw, thanks Anna for working on this! > > I've had a look at the list and I have some questions: > > * HotRodAsyncReplicationTest: I don't think it should be a client TCK test. > There's nothing the client does

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

On Thu, May 4, 2017 at 7:22 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > On 4 May 2017 at 12:03, Dan Berindei <dan.berin...@gmail.com> wrote: >> >> Personally I'm more worried about how our externalizers for JDK >> classes are going to work: it's going to be

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

If it's just private packages, then we won't have to change the API ;) Personally I'm more worried about how our externalizers for JDK classes are going to work: it's going to be hard to say we support Java 9 and at the same time ask users to add a bunch of --add-opens [1] to their JVM arguments.

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

machine. Cheers Dan On Thu, May 4, 2017 at 7:03 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > If it's just private packages, then we won't have to change the API ;) > > Personally I'm more worried about how our externalizers for JDK > classes are going to work: it's going to

Re: [infinispan-dev] Write-only commands

On Wed, Jun 28, 2017 at 10:17 AM, Radim Vansa <rva...@redhat.com> wrote: > On 06/27/2017 03:54 PM, Dan Berindei wrote: >> On Tue, Jun 27, 2017 at 2:43 PM, Adrian Nistor <anis...@redhat.com> wrote: >>> I've said this in a previous thread on this same issue, I will r

Re: [infinispan-dev] A tool for adjusting configuration

I suggest Java, any other language will be used as an excuse to leave all the maintenance work to you :) Dan On Mon, Aug 28, 2017 at 5:05 PM, Katia Aresti wrote: > Hi ! > > What about Golang ? > > Cheers, > > Katia > > On Mon, Aug 28, 2017 at 1:41 PM, Sebastian Laskawiec

Re: [infinispan-dev] Replacing IRC

Discourse [1] is more of a forum replacement than a chat, but I'd still like to suggest it. I hate it how in IRC you never know when a user has finished their idea and it's safe to start replying, and typing notifications don't really work for me :) Dan [1]: https://meta.discourse.org/ On

[infinispan-dev] IRC meeting logs 2017-11-20

Hi all Here are the logs of today's IRC meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-11-20-15.09.log.html Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

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

Hi everyone JBott wasn't available, so the meeting logs are available here: https://gist.github.com/danberindei/6d4d7e742eba41b0fb1bcba0ee735a8e Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

Re: [infinispan-dev] (no subject)

Yes, JGroupsTransport wasn't failing x-site requests when the remote site was unreachable: ISPN-9113 [1] When I first started the migration away from MessageDispatcher I was hoping to use the bridge view from RELAY2 to detect unreachable sites, but then I realized only the site master sees the

Re: [infinispan-dev] Weekly Infinispan IRC logs 2018-01-29

Hi all I missed the meeting yesterday as well. I was on PTO for most of last week. I spent Mon and Tue polishing the pull request for ISPN-8693, but unfortunately I didn't finish and I had to open a new PR yesterday [1]. I think I found a retry bug while checking for possibly-related test

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

forkJvmArgs used to be "-Xmx2G" before ISPN-8478. I reduced the heap to 1G because we were trying to run the build on agent VMs with only 4GB of RAM, and the 2GB heap was making the build run out of native memory. I've yet to see an OOME in the core tests, locally or in CI. But I also included

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

. Cheers Dan On Thu, Feb 15, 2018 at 1:59 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > Hmmm, I didn't notice that I was running with -XX:+UseG1GC, so perhaps our > test suite is a pathological case for the default collector? > > [INFO] Total time: 12:45 min > GC Time: 52.593

Re: [infinispan-dev] Best practices for Netty version clashes

The application POM could use dependency convergence [1], but we probably can't (and shouldn't) use the plugin in the BOM and enforce it's usage in applications. Dan [1]: http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html On Thu, Feb 15, 2018 at 12:52 PM, Sebastian

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

, Feb 15, 2018 at 1:39 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > And here I was thinking that by adding -XX:+HeapDumpOnOutOfMemoryError > anyone would be able to look into OOMEs and I wouldn't have to reproduce > the failures myself :) > > Dan > > > On Thu, Fe

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

there are quite some MBeans according to >> JConsole. I guess it would be good to check if we're not leaking the >> MBean registration, and therefore leaking (stopped?) CacheManagers >> from there? >> >> Even near the beginning of the tests, when forcing a full GC I see

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

that we've added in the last year or so. Cheers Dan On Fri, Feb 16, 2018 at 8:05 AM, Dan Berindei <dan.berin...@gmail.com> wrote: > Yeah, I got a much slower run with the default collector (parallel): > > [INFO] Total time: 17:45 min > GC Time: 2m 43s > Compile time: 18m 20s >

[infinispan-dev] Weekly IRC meeting logs 2018-02-19

Here are the logs of this week's IRC meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2018/infinispan.2018-02-19-15.02.log.html I forgot to send out the logs of last week's meeting, so I'm including them here as well:

Re: [infinispan-dev] ci.infinispan.org

Thanks Tristan! Looking at the git fetch command line I'm not sure it should work at all: --depth 10 is at the end, but man git fetch says it should be before the refspec. And yet I never suspected it was the cause :) I would have liked to also fetch a single branch, that would have made the

[infinispan-dev] PSA: How to debug an integration test

I had to debug some JMX stuff today and I remembered that Gustavo wanted a guide for debugging ITs, so here goes: 1. Build the server mvn install -DskipTests -am -pl server/integration/testsuite 2. Unpack the server in the testsuite module mvn test -pl server/integration/testsuite 3. Try to

<    2   3   4   5   6   7