[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

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] 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] 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] 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 >

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] 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] 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?

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] 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

[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] 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

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] 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 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 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 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 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] 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] 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.

[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] 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] 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] 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] 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?

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] 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] 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

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] 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] 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] 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).

[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] 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

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] 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

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] 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] 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

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] 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

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] 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] 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] 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

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] 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] Calling getCache with a template and defined configuration

I forgot to mention users can define their caches with ... if they want inheritance. So we don't need a way to merge configurations at this level. On Mon, Feb 27, 2017 at 4:52 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > I would go for option 2. > > We already starte

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

I still think WSC should be enabled by default, but we probably missed the 9.0 train. I see the 8.0 discussion also included batching, i.e. hiding the WSC options and forcing batching to use optimistic locking w/out WSC (currently batching allows any locking type, but batch transactions are

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

Finally! ;) Superficially the LocalModeNoPassivationTest and FunctionalCachestoreTest failures also look like they're caused by the data container change. Dan On Thu, Feb 23, 2017 at 2:28 PM, William Burns wrote: > All of the tests that failed with "The key was not

Re: [infinispan-dev] Classloader leaks?

After looking into this some more... TestNGTestListener does report 1262 leaked HotRodServerWorker and MemcachedServer worker threads at the end of the compatibility-mode-it test suite, so I'd say we probably do have a leak. The tests do seem to shut down their servers at the end, maybe someone

Re: [infinispan-dev] Classloader leaks?

On my system, `cat /proc/sys/fs/file-nr` reports 24838 used FDs, and that goes up to 29030 when running the infinispan-compatibility-mode-it tests. Since there are only 78 tests, a leak is quite possible, but I wouldn't say 4K open files (or sockets, more likely) really is a deal-breaker. Cheers

Re: [infinispan-dev] Classloader leaks?

I've been running with an limit of 10240 file descriptors for a while now, and I've never had problems (unless you count the time I upgraded gnome-terminal and it started ignoring my /etc/security/limits.conf). The CI agents also run the full build with a file descriptors limit. Dan On

Re: [infinispan-dev] Default TCP configuration is broken.

+1 to add FRAG3 back in, with frag_size="200k" to make fragmentation less likely, yet stay under max_credits * min_threshold. Dan On Wed, Feb 22, 2017 at 9:41 PM, Alan Field wrote: > > > - Original Message - >> From: "Pedro Ruivo" >> To:

Re: [infinispan-dev] Major version cleaning

On Wed, Feb 22, 2017 at 10:53 AM, Radim Vansa <rva...@redhat.com> wrote: > On 02/22/2017 09:11 AM, Dan Berindei wrote: >> On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa <rva...@redhat.com> wrote: >>> On 02/21/2017 07:14 PM, Dan Berindei wrote: >>>> But doesn

Re: [infinispan-dev] Major version cleaning

On Tue, Feb 21, 2017 at 8:28 PM, Radim Vansa <rva...@redhat.com> wrote: > On 02/21/2017 07:14 PM, Dan Berindei wrote: >> But doesn't the functional API's evalMany() provide something very >> close to the API you're suggesting? >> >> Dan >> >> >>

Re: [infinispan-dev] Major version cleaning

But doesn't the functional API's evalMany() provide something very close to the API you're suggesting? Dan On Tue, Feb 21, 2017 at 7:55 PM, Radim Vansa wrote: > On 02/21/2017 05:16 PM, Tristan Tarrant wrote: >> On 21/02/17 16:29, Sanne Grinovero wrote: You haven't

Re: [infinispan-dev] Major version cleaning

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 20, 2017 at 8:02 PM, Sanne Grinovero <sa...@infinispan.org> >> wrote: >>> -1 to

Re: [infinispan-dev] Major version cleaning

+1 to remove the async transactional modes +1 to remove batching I'm ambivalent about the tree module. I think we should be able to get it on a better footing by using the transactions API, but I'm unsure about the amount of work needed. The biggest problem with the tree module and batching, as

Re: [infinispan-dev] Major version cleaning

On Mon, Feb 20, 2017 at 8:02 PM, 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. It's easy to find several > iterations of rants of mine on this mailing list,

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

Oops, I thought I had replied to this... On Thu, Jan 19, 2017 at 6:11 PM, 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

Re: [infinispan-dev] My weekly report

Here is the log for the full meeting: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-02-13-15.03.log.html Cheers Dan On Mon, Feb 13, 2017 at 3:42 PM, Tristan Tarrant wrote: > Hi guys, > I won't be able to attend this week's IRC

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

I have some small comments on the blog post. I didn't read almost any of the code, so I guess I match the experience of a typical reader :) 1. Can you really use eviction="COUNT", like for the other memory types? 2. The address-count name is a bit odd, as it invites comparison with the native

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] 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] 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] How to improve our PR queue

I would also suggest avoiding +1/LGTM comments. It's enough to have the author and the integrator responsible in case something goes wrong, we don't need to "spread the blame" by having multiple +1 comments. "LGTM, but" is fine if there's a specific area that you have doubts about, and you're

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

e level is completely impractical in production, >> >> We do it all the time when there's no better option to debug an issue. >> (generally for as short a period as possible if it's production) >> >> -Dennis >> >> > but that info (or, I'd say 80% of >>

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] if (trace) logger.tracef - it makes sense

I should stress that we only cache `isTraceEnabled()` in a static field. Debug logging can still be enabled or disabled on the fly. Cheers Dan On Fri, Sep 30, 2016 at 3:14 PM, Wolf Fink wrote: > Ok, > > thanks for clarifying it. > > So there is a factor of 3 for the test if

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] 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 Mon, Sep 26, 2016 at 10:36 AM, Radim Vansa wrote: > Hi all, > > I have realized that fine grained maps don't work reliably with > write-skew check. This happens because WSC tries to load the entry from > DC/cache-store, compare versions and store it, assuming that this >

Re: [infinispan-dev] Hot Rod testing

On Thu, Sep 15, 2016 at 7:42 PM, Alan Field wrote: > I also like this idea for a Unit-Based TCK for all clients, if this is > possible. > >> - we identify and group the tests depending on their scope (basic >> protocol ops, bulk ops, topology/failover, security, etc). A client

Re: [infinispan-dev] Unwrapping exceptions

On Tue, Aug 30, 2016 at 1:11 PM, Sanne Grinovero wrote: > Yes please make sure that the kind of end users exceptions are the > same for the client, regardless if the originator happens to be an > owner as well. > > It's valuable to know that the exception happened on another

Re: [infinispan-dev] SKIP_CACHE_LOAD and write skew check

+1 to honor it. I should have done it back when I did ISPN-5643 [1], but I guess I was afraid about breaking more tests. Note that before ISPN-5643 conditional writes also used to ignore SKIP_CACHE_LOAD, and the javadoc encouraged users to enable it together with SKIP_REMOTE_LOOKUP. [1]:

Re: [infinispan-dev] Unwrapping exceptions

-1, I don't think we need to protect the user from knowing that his lambda was executed on a remote node. On the contrary, it might help him/her with debugging. FWIW, I don't think the cache should ever throw the exact exception that the lambda raised - I'd always wrap it in some kind of

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] Switch to AffinityPartitioner by default, or even enforce it

Is there any way that AffinityPartitioner could work with HotRod, though? On Fri, Aug 19, 2016 at 5:44 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > On 19 August 2016 at 15:39, Dan Berindei <dan.berin...@gmail.com> wrote: >> I just had a discussion with Adria

Re: [infinispan-dev] Switch to AffinityPartitioner by default, or even enforce it

a key partitioner that knows protobuf and can parse a single field from the object. So I'd like to withdraw my support for making AffinityPartitioner the default :) Cheers Dan On Fri, Aug 19, 2016 at 5:20 PM, Dan Berindei <dan.berin...@gmail.com> wrote: > On Thu, Aug 18, 2016 at 6:12

Re: [infinispan-dev] Switch to AffinityPartitioner by default, or even enforce it

On Thu, Aug 18, 2016 at 6:12 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > On 18 August 2016 at 14:44, Dan Berindei <dan.berin...@gmail.com> wrote: >> First, a question: doesn't query already configure its internal caches >> to use the AffinityPartitioner? Does it

Re: [infinispan-dev] Switch to AffinityPartitioner by default, or even enforce it

First, a question: doesn't query already configure its internal caches to use the AffinityPartitioner? Does it need the application caches to have AffinityPartitioner enabled, too? I'm ok with making AffinityPartitioner the default key partitioner: the less configuration the user has to change to

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

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. True, if there's a bug that causes the request to fail immediately and the client retries without pause for 1 minute, it can generate a lot of unnecessary load. So perhaps

Re: [infinispan-dev] Infinispan URL format

+1, a URL that gives you a different CacheManager every time you use it doesn't seem very useful. JCache also requires the the CacheManager returned for one URL to be more or less constant: * Multiple calls to this method with the same {@link URI} and * {@link ClassLoader} must return the

Re: [infinispan-dev] Adding tests for new cache mode

On Tue, May 17, 2016 at 3:26 PM, Tristan Tarrant wrote: > On 17/05/2016 14:10, Radim Vansa wrote: >> Hi, >> >> I've decided to start working on Scattered Cache [1][2] POC. I'd like to >> use most of the tests for distributed mode, but just extending >> DistXxxTest with

Re: [infinispan-dev] ClusteredGetCommand vs. SingleRpcCommand

I wasn't present in the JBoss Cache days either, but I'm guessing it's to allow "special" processing of the command and/or results outside of the interceptor chain. It also saves a bit on the marshalling cost, as the serialization of SingleRpcCommand isn't terribly efficient. In general, I

[infinispan-dev] Weekly Infinispan IRC meeting 2016-05-09

Hi everyone Here are the logs from our weekly meeting on #infinispan: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-05-09-14.07.log.html Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

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

+1 to deprecate it, then we can deprecate AtomicHashMap as well :) OTOH the scenario in the question seems really basic, we should have some distributed mode tests to cover it, even if we decide to deprecate the module. Dan On Thu, Apr 7, 2016 at 3:20 PM, Tristan Tarrant

  1   2   3   4   5   6   7   >