Re: [infinispan-dev] Design session today

On 08/09/2013 07:55 AM, Mircea Markus wrote: > The only argument I found was that's the way the spec does it :-) I > think CacheLoader + CacheWriter is a nice OOP design, but is rather > theoretical. In all external users scenarios I know, the interaction > with the store is read+write so most o

Re: [infinispan-dev] CacheLoader and CacheStore

My vote is #2, as it simplifies the code and removes redundant code (fewer chances for bugs). We've already had to fix one bug where the code reading the cache loader configuration was different than reading the cache store configuration. -Dennis On 08/09/2013 01:21 PM, Mircea Markus wrote: >

Re: [infinispan-dev] CacheLoader and CacheStore

On 08/14/2013 04:21 AM, Radim Vansa wrote: > On 08/13/2013 04:50 PM, Mircea Markus wrote: >> On 13 Aug 2013, at 15:30, Galder Zamarreño wrote: >> >>> On Aug 13, 2013, at 12:20 PM, Mircea Markus wrote: >>> On 13 Aug 2013, at 07:59, Galder Zamarreño wrote: > My preference is for #1.

Re: [infinispan-dev] Consistent hashes and Hot Rod

Have you done a prototype and tested it to see if it improves performance? "Inefficient" is a relative term. The difference in .3 billionths of a second and .6 billionths of a second (rough numbers from a quick test) is huge percentage wise, but only makes a difference in a tight loop around th

Re: [infinispan-dev] To squash or not to squash

I think this has the biggest effect on those of us porting fixes to other versions. When porting changes, I've seen issues with both single commits and multiple commits: 1) When doing one commit, it's too tempting to bring in unrelated changes, such as unrelated formatting changes. This has

Re: [infinispan-dev] The windup of 6.0.0

On 10/17/2013 05:26 AM, Bela Ban wrote: > The other thing to look at is the apparent cost of Thread.setName(): if > we cannot avoid thread many creations, we could experiment with *not* > naming threads, although this is IMO not a good idea. I agree that not naming the threads is a bad idea. The

Re: [infinispan-dev] design for cluster events (wiki page)

On 10/30/2013 02:33 PM, Mircea Markus wrote: > Okay, and now the good URL (3rd try): > https://github.com/infinispan/infinispan/wiki/Clustered-listeners There are a couple of things missing in the Filter and Convertor: - What type of event? - isPre? For instance, for CacheEntryModified the list

Re: [infinispan-dev] design for cluster events (wiki page)

On 10/31/2013 02:18 AM, Bela Ban wrote: > >> Also if we did have read only, what criteria would cause those nodes >> to be writeable again? > Once you become the primary partition, e.g. when a view is received > where view.size() >= N where N is a predefined threshold. Can be > different, as long a

Re: [infinispan-dev] configuration toProperties

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

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

On 12/06/2013 08:52 AM, Mircea Markus wrote: > Some notes: > > "This means that the Hot Rod protocol will be extended so that operation > headers always carry a Source ID field." > - shall we add a new intelligence level to handle this? Besides reducing the > payload, would allow upgrading the ja

Re: [infinispan-dev] Ditching ASYNC modes for REPL/DIST/INV/CacheStores?

It would be a loss of functionality. As a common example, the AS web session replication cache is configured for ASYNC by default, for performance reasons. But it can be changed to SYNC to guarantee that when the request finishes that the session was replicated. That wouldn't be possible if you

Re: [infinispan-dev] Ditching ASYNC modes for REPL/DIST/INV/CacheStores?

On 02/19/2014 12:57 AM, Galder Zamarreño wrote: > On 31 Jan 2014, at 08:32, Dennis Reed wrote: > >> It would be a loss of functionality. >> >> As a common example, the AS web session replication cache is configured >> for ASYNC by default, for performance reasons. &g

Re: [infinispan-dev] grouping and GridFS

It doesn't make sense. :) The reason grid file systems exist is to distribute the file around the cluster. (both for performance so the network interface of a single server isn't a bottleneck, and for disk space so the available space on a single server isn't a bottlenect) If you don't want t

Re: [infinispan-dev] Query.getResultSize() to be available on the simplified DSL?

Providing methods that work sometimes and don't work other times is generally a bad idea. No matter how much you document it, users *will* try to use it and expect it to always work (either because they didn't read the docs that say otherwise, they think they'll stick to a configuration where i

Re: [infinispan-dev] Query integration tests performance and JGroups

Can you double check that you're interpreting the profiler data correctly (specifically with respect to where threads are spending time versus where they are using CPU)? The spot you pointed out *should* show up as a place where threads spend lots of time, as these threads just sit waiting in

Re: [infinispan-dev] Issue with JGroups config files in ispn-core

+1 to changing the name/directory. -100 to changing the order of where it's looked for instead. All resource lookups should use the normal rules for finding resources. Don't change standard behavior without a *very* good reason. Doing anything special (like META-INF/_internal/jgroups-udp.xml) is

Re: [infinispan-dev] Weird ClassCastException ..

It looks like the data was written by a different version of PutKeyValueCommand than is trying to read it. Make sure you're not mixing ISPN versions in the cluster and/or accidentally clustering with another instance outside your test? -Dennis On 08/04/2014 06:33 PM, Sanne Grinovero wrote: > I

Re: [infinispan-dev] Clustering standalone Infinispan w/ WF running Infinispan

The error in that link is when reading the class data from the serialized stream. EAP (and therefore I assume JDG server, but I haven't confirmed) uses a custom class resolver, which includes the JBoss Modules module that the class came from in the serialized class data. Library mode JDG would

Re: [infinispan-dev] About size()

Since size() is defined by the ConcurrentMap interface, it already has a precisely defined meaning. The only "correct" implementation is E. The current non-correct implementation was just because it's expensive to calculate correctly. I'm not sure the current impl is really that useful for an

Re: [infinispan-dev] Multi get API

On 03/26/2015 09:46 AM, Radim Vansa wrote: > On 03/26/2015 03:00 PM, Sanne Grinovero wrote: >> On 26 March 2015 at 13:43, William Burns wrote: >>> On Thu, Mar 26, 2015 at 8:50 AM, Sanne Grinovero >>> wrote: In terms of naming, I'd prefer _getMulti_. My reasoning is it's nice if has a c

Re: [infinispan-dev] Strict Expiration

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 > > wrote: >> >> On Tue, Jul 14, 2015 at 4:41 AM Dan Berindei >> mailto:dan.berin...@gmail.com>> wrote: >> >>

Re: [infinispan-dev] Distributed Executor remote cancellation

On 03/30/2016 12:26 PM, Sanne Grinovero wrote: > On 30 March 2016 at 17:40, William Burns wrote: >> You can still attempt to cancel a task. This email is specifically about >> interruption though. Let me explain the nuances in a bit more detail. >> >> With the suggestion we would still fully sup

Re: [infinispan-dev] Remote execute null return (ISPN-6406)

A related question -- do you want to support null in the protocol? Not all languages even have a concept of null. So you do need to make a decision whether to support null to the exclusion of languages that don't have it (or make Hot Rod more complicated to use in those languages), or disallow nu

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

As Wolf noted, caching the trace flag is bad when trying to debug issues. Don't do it! It's not worth breaking the logging semantics for a nano-second level performance difference. (if your trace is being called enough for that tiny impact to make any real difference, that trace logging is going

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

On 10/03/2016 08:43 AM, Radim Vansa wrote: > Aren't we investing a bit too much time to this? The trace level was > cached for ages, has anyone ever complained? I have. https://issues.jboss.org/browse/JBCACHE-1625 Looks like I just never copied it over to the ISPN JIRA. :) > Turning on trace

Re: [infinispan-dev] Classloader leaks?

Are those actually 2 million *unique* descriptors? I've seen lsof output that listed many duplicates for the same file descriptor (one for each thread?), making the list appear much larger than it really was. -Dennis On 02/22/2017 02:25 PM, Sanne Grinovero wrote: > Hi all, > > our documentatio

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

+1 to authentication and encryption by default. This is 2017, that's how *everything* should be configured. -1 to making it easy to trust all certs. That negates the point of using encryption in the first place and should really never be done. If it's too hard to configure the correct way that

Re: [infinispan-dev] Documentation code snippets

Definitely #1. They serve two completely separate purposes. I'm glad to see this, as incorrect examples in documentation is a pet peeve of mine. :) -Dennis On 05/03/2017 09:14 AM, Jiri Holusa wrote: > Moving this to infinispan-dev. > > I've just issued a PR [1], where I setup the code snippe

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

Or take it one step further, and just get rid of the uber jars. Because there is really only a single benefit to uber jars: save maybe a minute the very first time you start a new project and are using a build system other than maven or similar. And there are a whole bunch of problems they cause.

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

Uber jars were never needed for maven. Their only purpose is to be able to add a single dependency in other build systems that don't already have automatic dependency management. -Dennis On 06/08/2017 01:04 PM, Alan Field wrote: > Wasn't the ability to add a single dependency to a project to st

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

On 08/11/2017 08:14 AM, Galder Zamarreño wrote: > 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 localport as the Hot Rod server port. As a result, when the client sends > something to

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

On 08/11/2017 11:50 AM, Galder Zamarreño wrote: > I must admit this scenario sounds very weird... how does Java allow you for a > local port to be bound to a port that's already in use by the server? It > doesn't make sense. You cannot bind to a port that's already in use. But if you're trying

Re: [infinispan-dev] Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...

On 10/15/2012 06:56 PM, Scott Marlow wrote: > All the better if I'm wrong, as we will solve both problems with one > fix. :) > > I don't see it yet though. I attached new logs to ISPN-2330 with a > little more information (clearer indication of when the problem is > caused in jbossas-clusterin

Re: [infinispan-dev] Fixing ISPN-2384 (data loss with concurrent activation/passivation)

On 11/02/2012 12:45 PM, Galder Zamarreño wrote: > Ok, my suggestion below is working now, but I'm not so sure the way the > activation interceptor works is the correct one. > > IMO, an activation, which involves removing an entry from the cache store > (and updating the stats), should only be don

Re: [infinispan-dev] HotRod server and Rolling Upgrades

I don't like #1. Seems more complicated, harder to maintain & debug than the others. In my opinion the best option would be #4 (eliminate the different formats), but that probably can't be done in a minor release? Between 2 and 3, I'd prefer #2, handling it in the base class so it's automat

Re: [infinispan-dev] a nice HTML5 console for Infinispan & a question on MBean names...

This is an invalid use of the MBean names. The keys in an ObjectName are unordered. It is a bug to depend on a specific ordering of the keys. -Dennis On 03/19/2013 10:07 AM, Manik Surtani wrote: > Hi James. > > Strange that no one else has responded to you on this list as yet; I'm all > for r

Re: [infinispan-dev] a nice HTML5 console for Infinispan & a question on MBean names...

On 03/20/2013 10:03 AM, James Strachan wrote: > On 19 March 2013 17:55, Dennis Reed wrote: >> This is an invalid use of the MBean names. >> >> The keys in an ObjectName are unordered. It is a bug to depend on a >> specific ordering of the keys. > If the order re

Re: [infinispan-dev] ISPN-263 and handling partitions

Some other alternatives for detecting a split: - a hard-coded number of nodes required for a quorum configured by the customer. This is what we recommend for HASIngletons when the customer wants to guarantee that something is running at most once in the cluster. - an alternative communicatio

Re: [infinispan-dev] Removal of AS7 compatibility parsers

From a support standpoint, I'd prefer the converters. It should be easier to debug any issues specific to one configuration parser. (It would have been MUCH better to only have one configuration format for everything, but it's too late for that now...) -Dennis On 04/18/2013 02:57 AM, Tristan

Re: [infinispan-dev] Suppressing state transfer via JMX

I see 2 potential issues: 1. How does the user know which node is the master to connect to, since the operations are a no-op on all the others? - instead of a no-op, what if the other nodes just forward the operation to the correct node? Then the user doesn't have to know who the c