Re: [infinispan-dev] Proposal - encrypted cache

If you ask Clement, it was quite a challenge to run one of the small JVM variant within the enclave. We would need a specific support at the VM level to do some piece of code within the enclave while others are not. On Thu 18-07-05 10:51, Sebastian Laskawiec wrote: >Just stumbled upon:

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

On Wed 18-05-30 11:16, Galder Zamarreno wrote: >On Tue, May 29, 2018 at 8:57 PM Adrian Nistor wrote: > >> Vittorio, a few remarks regarding your statement "...The alternative to >> this is to develop a protostream equivalent for each supported language and >> it doesn't seem really feasible to

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

Right. Here we are talking about a gRPC representation of the client server interactions. Not the data schema stored in ISPN. In that model, the API is compiled by us and handed over as a package. > On 29 May 2018, at 15:51, Sanne Grinovero wrote: > > > >> On 29 May 2018 at 13:45, Vittorio

Re: [infinispan-dev] Feedback on MultimapCache

Stupid question. Hot Rod does not have near cache invalidation already ? Does not suit your needs or not implemented for multimapcache? > On 9 Oct 2017, at 18:30, Radim Vansa wrote: > >> On 10/09/2017 03:04 PM, Thomas SEGISMONT wrote: >> Hi, >> >> I've created a branch in

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

Sanne’s idea of a calculator where you input your data size needs and it offers pod number / pod size options. But we will have to offer that in the doc or something. Not as part of the service catalog UI in its current incarnation. Emmanuel > On 28 Sep 2017, at 15:13, Emmanuel Bernard <

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

t; So how about exposing two parameters - Xms/Xmx and Total amount of memory for > Pod (Request = Limit in that case). Would it work for you? > > On Thu, Sep 28, 2017 at 8:38 AM Emmanuel Bernard <emman...@hibernate.org > <mailto:emman...@hibernate.org>> wrote: > Seb

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

Sebastian, What Galder, Sanne and others are saying is that in OpenShift on prem, there is no or at least a higher limit in the minimal container memory you can ask. And in these deployment, Infinispan should target the multi GB, not 512 MB. Of course, *if* you ask for a guaranteed 512MB, then

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

When you deploy a RDBMS on OpenShift, it is secured by default I think and it's not a big deal. It is possible to read back secrets in OpenShift in case you forgot them. Maybe there is a way to either document that better, maybe having the same password between console and cache by default is

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

If built-in solutions like what Tristan proposed don't work. Copnsider Windup, it must likely have ways to transform configurations. Windup is a generic tool to migrate from some version of X to some versions of Y. Worth talking to the team. Emmanuel On Mon 17-08-28 11:41, Sebastian Laskawiec

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

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 pops into your mind and you can go further. > On 18 Jul 2017, at 15:05, Sebastian Laskawiec wrote: > > I have mixed feelings

Re: [infinispan-dev] On the scattered cache blog post

On Tue 17-07-04 13:21, Radim Vansa wrote: >2. Setting numOwners to anything but 1 (or keeping it at default value) >throws an exception when the configuration is validated. XML does not >expose such attribute. Yes, you've read correctly: 1 is the num owners >because we don't keep more owners in

Re: [infinispan-dev] 9.1.0 endgame

> On 19 Jun 2017, at 12:22, Tristan Tarrant wrote: > > 9.1.0.Final - 14th July Better be named Bastille one way or another. https://www.ratebeer.com/beer/revolution-bastille/179085/ ___ infinispan-dev mailing list

Re: [infinispan-dev] Reactive Streams + RxJava

You’re thinking about a pure implementation play, correct? RxJava or the Reactive Stream constructs would not be exposed to the user as API. Am I correct? Also for posterity, we had backchannel chats about it and you said you felt vert.x was not necessarily addressing your needs. Could you

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

To Sanne’s point, I think HTTP(/2) would be a better longer term path if we think we can make it as efficient as current HR. But let’s evaluate the numbers of cycles to reach that point. Doing Seb’s approach might be a good first step. Speaking of Sebastian, I have been discussing with Burr,

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

> On 25 May 2017, at 10:00, Sebastian Laskawiec wrote: > . As it turns out we can use Optionals anywhere, except method returning some > objects which are not getters. You can't use it on non getter return types ? Why ? > > It is also worth to say that both gentlemen

[infinispan-dev] How to Build a Non-Volatile Memory DBMS

https://www.cs.cmu.edu/~jarulraj/pages/sigmod_2017_tutorial.html ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] TLS/SNI support for Relay protocol

Sebastian, Do you know if OpenShift has or plans to have some VPN or VPN like capabilities to bridge two "cross site" projects? It would probably be a faster and more generic solution than going through HTTP. Emmanuel On Tue 17-04-25 13:04, Sebastian Laskawiec wrote: >Hey Bela! > >I've been

Re: [infinispan-dev] Infinispan Query API simplification

We did discuss something like cache.using(QueryableCache.class).createQuery("...").[build].list(); With some service locator system to have extensible and pluggable modules. We did discuss a potential problem but I forgot what it was. Emmanuel > On 20 Apr 2017, at 14:08, Tristan Tarrant

Re: [infinispan-dev] Infinispan Designs repository

Should we (as in someone specific that is not me) migrate all the GitHub proposal / design pages from the Wiki? > On 31 Mar 2017, at 14:25, Tristan Tarrant wrote: > > As was pointed out by Sebastian, GitHub's wiki doesn't really take > advantage of the wonderful review

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

compensate from that. Emmanuel > On 16 Dec 2016, at 17:00, Tristan Tarrant <ttarr...@redhat.com> wrote: > > > > On 16/12/16 16:30, Emmanuel Bernard wrote: > >> The Emmanuel Dec 9th proposal handles I think the case of topology changes >> and nodes going down. &g

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

> On 16 Dec 2016, at 16:25, Emmanuel Bernard <emman...@hibernate.org> wrote: > > >> On 16 Dec 2016, at 13:38, Tristan Tarrant <ttarr...@redhat.com> wrote: >> >> On 16/12/16 13:12, Emmanuel Bernard wrote: >>> >>>> On 16 Dec

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

> On 16 Dec 2016, at 13:38, Tristan Tarrant <ttarr...@redhat.com> wrote: > > On 16/12/16 13:12, Emmanuel Bernard wrote: >> >>> On 16 Dec 2016, at 09:48, Tristan Tarrant <ttarr...@redhat.com> wrote: >>> >>> On 16/12/16 09:34, Emmanuel Ber

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

> On 16 Dec 2016, at 09:48, Tristan Tarrant <ttarr...@redhat.com> wrote: > > On 16/12/16 09:34, Emmanuel Bernard wrote: >>> Yes, the above design is what sprung to mind initially. Not sure about >>> the need of keeping the log in memory, as we would probably nee

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

> On 16 Dec 2016, at 08:46, Tristan Tarrant <ttarr...@redhat.com> wrote: > > On 09/12/16 18:25, Emmanuel Bernard wrote: >> The total order would not be global but per key. >> Each node has a Debezium connector instance embedded that listens to the >> operation

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

> On 15 Dec 2016, at 16:09, Sanne Grinovero wrote: > > Thanks Randall, > those clarifications have been great. > > Emmanuel: some of your statements conflict with Randall's > clarifications and with the feasibility points I've been pointing at. > You say "collect *all*

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

> On 15 Dec 2016, at 15:59, Gustavo Fernandes <gust...@infinispan.org> wrote: > > > > On Thu, Dec 15, 2016 at 2:53 PM, Emmanuel Bernard <emman...@hibernate.org > <mailto:emman...@hibernate.org>> wrote: > >> On 15 Dec 2016, at 11:18, Gustavo Ferna

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

> On 15 Dec 2016, at 11:18, Gustavo Fernandes <gust...@infinispan.org> wrote: > > On Thu, Dec 15, 2016 at 9:54 AM, Emmanuel Bernard <emman...@hibernate.org > <mailto:emman...@hibernate.org>> wrote: > The goal is as followed: allow to collect all changes to

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

Read my email from Dec 9th and the one from today and let me know which question is not sufficiently answered. I can try and clarify or refine. > On 15 Dec 2016, at 14:36, Tristan Tarrant wrote: > > On 12/12/16 16:13, Sanne Grinovero wrote: >> In short, what's the ultimate

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

The goal is as followed: allow to collect all changes to push them to Debezium and thus Kafka. This need does not require to remember all changes since the beginning of time in Infinispan. Just enough to: - let Kafka catchup assuming it is the bottleneck - let us not lose a change in Kafka when

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

Randall and I had a chat on $subject. Here is a proposal worth exploring as it is very lightweight on Infinispan's code. Does an operation has a unique id sahred by the master and replicas? If not could we add that? The proposal itself: The total order would not be global but per key. Each node

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

I like Ickle and LQID personally. And Adrian is way too reasonable on a name thread ;) On Mon 16-10-17 9:07, Tristan Tarrant wrote: >Hi all, > >something trivial and fun for a Monday morning. > >I've just issued a PR [1] to update the codename for Infinispan 9.0. > >And while we're at it, let's

Re: [infinispan-dev] Some memory usage data points of the Hibernate Search / Lucene query engine.

To put some context, that's a very unfavorable query for Lucene (sort by data other than score, retrieve all the data set). On Mon 16-10-24 17:42, Sanne Grinovero wrote: >Hi all, >at our last meeting we had some chats about heap usage at runtime. > >I wasn't actually investigating this, but since

Re: [infinispan-dev] Hot Rod testing

On Fri 2016-09-23 17:33, Galder Zamarreño wrote: >Maybe some day we'll have a Java-based testsuite that more easily allows >continous testing. Scala, through SBT, do have something along this lines, so >I don't think it's necessarily impossible, but we're not there yet. And, as I >said above,

Re: [infinispan-dev] Hot Rod testing

>> 1. How do you verify that a Javascript client works the way a Javascript >> program would use it? >> IOW, even if you could call JS from Java, what you'd be verifying is that >> whichever contorsionate way of calling JS from Java works, which might not >> necessarily mean it works when a real

Re: [infinispan-dev] Kubernetes/OpenShift Rolling updates and configuration changes

Considering very few options can be changed at runtime safely, should we rather focus of a strategy where we start a new grid and populate it with the old grid before flipping the proxy to the new one? On Mon 2016-07-18 17:12, Tristan Tarrant wrote: > On 14/07/16 12:17, Sebastian Laskawiec wrote:

Re: [infinispan-dev] Infinispan URL format

On Wed 2016-06-01 9:31, Scott Marlow wrote: > > The [cachemanager] part is for multi-tenant servers (Hot Rod doesn't > > currently support this, so this is forward-looking). > > Obviously we will support all of the HotRod properties for specifying > > things like security, etc. > > Once you are

Re: [infinispan-dev] Infinispan URL format

> On 31 May 2016, at 13:33, Galder Zamarreño wrote: > >> In the past there has been talk of representing a connection to >> Infinispan using a URL, in particular for HotRod. >> The Hibernate OGM team is now working on adding NoSQL datasources to >> WildFly, and they've

Re: [infinispan-dev] Multi tenancy support for Infinispan

Is the router a software component of all nodes in the cluster ? Does the router then redirect all request to the same cache-container for all tenant? How is the isolation done then? Or does each tenant have effectively different cache containers and thus be "physically" isolated? Or is that

Re: [infinispan-dev] Google load balancer design

On Tue 2016-03-22 8:56, Radim Vansa wrote: > On 03/22/2016 08:24 AM, Emmanuel Bernard wrote: > > http://blog.acolyer.org/2016/03/21/maglev-a-fast-and-reliable-software-network-load-balancer/ > > > > Interesting read. Some data points I extracted. > > > > 350

[infinispan-dev] Google load balancer design

http://blog.acolyer.org/2016/03/21/maglev-a-fast-and-reliable-software-network-load-balancer/ Interesting read. Some data points I extracted. 350 ns per parquet. Ensuring a 300us during load. Some math I was not aware of: [quote] -- Let N be the size of a VIP’s backend pool. A table is

Re: [infinispan-dev] Uber jars - how do we want to use them

On Mon 2016-03-14 11:21, Sebastian Laskawiec wrote: > I took a look at Nexus download statistics and Infinispan Uberjars are > about 7% of our downloads (of course this calculation has been based on our > JBoss Nexus instance and we have no data from other mirrors). It's actually the opposite,

Re: [infinispan-dev] Hot Rod encoding

Note that in a future version of hibernate search - soon I hope, the encoding will no longer be a problem. You will be able to provide a navigation/traversal API that will know how to read things from your blob. It's called free form entity by its friends. > On 17 févr. 2016, at 12:35, Galder

Re: [infinispan-dev] Event log

> On 13 Nov 2015, at 18:02, Sanne Grinovero wrote: > > > Although, I'm surprised that you want to use an actual logging > category. The API for that is awful for rich events; I do realize that > "text" is a rather standard API, and stuff like ELK are great because > they

Re: [infinispan-dev] Event log

> On 16 nov. 2015, at 15:04, Emmanuel Bernard <emman...@hibernate.org> wrote: > > >> On 13 Nov 2015, at 18:02, Sanne Grinovero <sa...@infinispan.org> wrote: >> >> >> Although, I'm surprised that you want to use an actual logging >> catego

Re: [infinispan-dev] Building the website

https://github.com/infinispan/infinispan.github.io/pull/17 > On 03 Sep 2015, at 14:12, Emmanuel Bernard <emman...@hibernate.org> wrote: > > Thanks to your blatant lack of help, I ended up writing a docker image to > edit the website. > I will contribute it as part of the in

Re: [infinispan-dev] Building the website

Thanks to your blatant lack of help, I ended up writing a docker image to edit the website. I will contribute it as part of the initial change I wanted to push. I hate you all ! :) Emmanuel > On 03 Sep 2015, at 09:36, Emmanuel Bernard <emman...@hibernate.org> wrote: > > I fo

[infinispan-dev] Building the website

I have had my share of bad Ruby dependency experiences in the past but for the love of me, I cannot make the Infinispan website build on Mac OS X 10.10.5. I’ve done rake clean[all] rake setup[local] Got into this problem https://gist.github.com/emmanuelbernard/6692c6f43237218d24fd

Re: [infinispan-dev] Interceptor stack for local caches

I am no expect at all of the code base. Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the

Re: [infinispan-dev] Interceptor stack for local caches

of selected cases like you are describing Radim. On 22 juin 2015, at 07:42, Emmanuel Bernard emman...@hibernate.org wrote: I am no expect at all of the code base. Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use? And that resonates

Re: [infinispan-dev] Interceptor stack for local caches

, Emmanuel Bernard emman...@hibernate.org wrote: BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU. So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones

Re: [infinispan-dev] Interceptor stack for local caches

Ah. Tristan told me these plans are already in motion in stages. On 22 juin 2015, at 08:09, Emmanuel Bernard emman...@hibernate.org wrote: Pushing the idea further, you can actually make the CacheImpl specifically tailored to the configuration of a given cache by using ASM or anything

Re: [infinispan-dev] org.infinispan.notifications.cachelistener.filter vs org.infinispan.filter

Should it be morphed into a FAQ? On 03 Mar 2015, at 16:23, Galder Zamarreño gal...@redhat.com wrote: Hmm, ok. It's true that down the line the remote events might morph into more specialised DSL-based remote event filter/conversion. I just wished the naming would have been a bit more

[infinispan-dev] [Query] Continuous queries 1-1 modify case

While discussing with Stelios, I realised that it is useful in some circumstances to receive a notification in case of a 1-1 transition. This diff captures the design improvements

Re: [infinispan-dev] JIRAs for a 7.0.3 release

While we are on a wish list for 7.0.3. We have found a regression from Infinispan 6 on (FineGrained)AtomicMap that is seriously impacting Hibernate OGM. ISPN-5088 We should get this one quickly to avoid people tripping over the concurrency concern the workaround implies. Emmanuel On 15 Dec

Re: [infinispan-dev] Improving the performance of index writers

HSEARCH-1699 looks good. A few comments. Maybe from a user point of you we want to expose the number of ms the user is ok to delay a commit due to indexing. Which would mean that you can wait up to that number before calling it a day and emptying the queue. The big question I have which you

Re: [infinispan-dev] Improving the performance of index writers

On 20 Oct 2014, at 14:10, Sanne Grinovero sa...@infinispan.org wrote: On 20 October 2014 12:59, Emmanuel Bernard emman...@hibernate.org wrote: HSEARCH-1699 looks good. A few comments. Maybe from a user point of you we want to expose the number of ms the user is ok to delay a commit due

Re: [infinispan-dev] Infinispan 7.1 plan

There is a difference between cherry picking and rebasing when it comes to reapply a work on top of a branch. Do you dislike both equally compared to a merge (aka railroad nexus git history approach)? On 20 Oct 2014, at 16:47, Tristan Tarrant ttarr...@redhat.com wrote: Hi guys, with the

Re: [infinispan-dev] Improving the performance of index writers

: On 20 October 2014 14:55, Emmanuel Bernard emman...@hibernate.org wrote: On 20 Oct 2014, at 14:10, Sanne Grinovero sa...@infinispan.org wrote: On 20 October 2014 12:59, Emmanuel Bernard emman...@hibernate.org wrote: HSEARCH-1699 looks good. A few comments. Maybe from a user point

Re: [infinispan-dev] Feedback and requests on clustered and remote listeners

to clean up. https://github.com/wburns/infinispan/tree/ISPN-4753 Thanks, - Will On Fri, Sep 26, 2014 at 4:06 AM, Emmanuel Bernard emman...@hibernate.org wrote: You lost me at actually ;) but if you have some code or even a gist showing how a user would use and interact

Re: [infinispan-dev] TopologySafe Map / Reduce

When wrestling with the subject, here is what I had in mind. The M/R coordinator node sends the M task per segment on the node where the segment is primary. Each per-segment M task is executed and is offered the way to push intermediary results in a temp cache. The intermediary results are stored

[infinispan-dev] TopologySafe Map / Reduce

Pedro and I have been having discussions with the LEADS guys on their experience of Map / Reduce especially around stability during topology changes. This ties to the .size() thread you guys have been exchanging on (I only could read it partially). On the requirements, theirs is pretty

Re: [infinispan-dev] Infinispan 7.0 feature freeze and future planning

Not so theoretical question. What about features that are being refined (like clustered / remote listener as seen int he recent days). Are these improvements to be removed under the feature freeze hammer. That would possibly impact our ability to do them in 7.x if APIs change. Or are they part

Re: [infinispan-dev] Feedback and requests on clustered and remote listeners

You lost me at actually ;) but if you have some code or even a gist showing how a user would use and interact with these changes, I can give you some feedback on the use cases I had in mind and if they fit. On 25 sept. 2014, at 15:20, William Burns mudokon...@gmail.com wrote: Actually

Re: [infinispan-dev] Feedback and requests on clustered and remote listeners

On 23 sept. 2014, at 18:17, Galder Zamarreño gal...@redhat.com wrote: On 18 Sep 2014, at 18:24, Emmanuel Bernard emman...@hibernate.org wrote: Hi all, I have had a good exchange on how someone would use clustered / remote listeners to do custom continuous query features. I have

Re: [infinispan-dev] Hot Rod Remote Events #3: Customizing events

On 23 sept. 2014, at 09:15, Radim Vansa rva...@redhat.com wrote: Please, consider also the corner cases such as overwriting already updated value, e.g. after OutdatedTopologyException. Sometimes the oldValue might not be correct (we probably can't evade this but I hope we can detect that

Re: [infinispan-dev] Feedback and requests on clustered and remote listeners

On 22 sept. 2014, at 19:23, William Burns mudokon...@gmail.com wrote: On Fri, Sep 19, 2014 at 12:39 PM, Emmanuel Bernard emman...@hibernate.org wrote: On 19 Sep 2014, at 17:09, William Burns mudokon...@gmail.com wrote: Comments regarding embedded usage are inline. I am not quite

Re: [infinispan-dev] Feedback and requests on clustered and remote listeners

On 23 Sep 2014, at 15:42, William Burns mudokon...@gmail.com wrote: Reread the other email again and actually it could be used to show different permutations like the retry case (eq RETRIED_CREATE), but it seems like the code in that one method would get pretty complex pretty fast having to

[infinispan-dev] Feedback and requests on clustered and remote listeners

Hi all, I have had a good exchange on how someone would use clustered / remote listeners to do custom continuous query features. I have a few questions and requests to make this fully and easily doable ## Value as bytes or as objects Assuming a Hot Rod based usage and protobuf as the

Re: [infinispan-dev] Data versioning

Mircea, Tristan, I proposed to Pierre to be an invited writer on blog.infinispan.org to talk about it and do a blog sized version of it. Any reason not to ? Emmanuel On Fri 2014-09-12 14:41, Pierre Sutra wrote: Hello, In the context of the LEADS project, we recently wrote a paper |1]

[infinispan-dev] Propagate the schema to the cachestore

A remark by Divya made me think of something. With Infinispan moving to the direction of ProtoBuf and schemas, cache store would greatly benefit from receiving in one shape or another that schema to transform a blob into something more structure depending on the underlying capability of the

Re: [infinispan-dev] OGM, Hot Rod and Grouping API

On 06 Jun 2014, at 15:04, William Burns mudokon...@gmail.com wrote: Does that answer your question? Because I’m not sure what you mean by the key being attached to the Tx. The difference is say you have a tx1 on thread 1 then on the same thread you ask for the group, if it is in the

Re: [infinispan-dev] OGM, Hot Rod and Grouping API

On 06 Jun 2014, at 15:29, Emmanuel Bernard emman...@hibernate.org wrote: On 06 Jun 2014, at 15:04, William Burns mudokon...@gmail.com wrote: Does that answer your question? Because I’m not sure what you mean by the key being attached to the Tx. The difference is say you have a tx1

Re: [infinispan-dev] JPA CacheStore doc

https://issues.jboss.org/browse/ISPN-4320 On 23 May 2014, at 12:47, Dan Berindei dan.berin...@gmail.com wrote: Please open a single JIRA for all of them. On Tue, May 20, 2014 at 10:29 AM, Emmanuel Bernard emman...@hibernate.org wrote: Hi guys, I was reading http://infinispan.org

[infinispan-dev] JPA CacheStore doc

Hi guys, I was reading http://infinispan.org/docs/7.0.x/user_guide/user_guide.html#_jpa_cache_store I have a few remarks and questions. The links on 7.3. Additional References to github lead to 404. Right under the 7. Section title, there is The Infinispan Community :icons: font Not

Re: [infinispan-dev] RAFT

On Fri 2014-05-16 8:22, Bela Ban wrote: Interesting, thanks for the link ! Makes me want to implement this in JGroups. Should be relatively easy with *static* membership. Different ballgame though with dynamic memberships... That's the same of these approaches. They require a static

Re: [infinispan-dev] Welcome to Gustavo

Welcome :) On Thu 2014-05-15 14:29, Sanne Grinovero wrote: Hi all, today we finally have Gustavo joining us as a full time engineer on Infinispan. He worked with Tristan and myself in Italy before we came to Red Hat, and was already a Lucene expert back then. He then joined Red Hat as a

Re: [infinispan-dev] [!] Reorganization of dependencies release process

Let's not overload the subject here. We can first approach the problem like Dan mentions by doing a tag for core in git and release in maven. Then every other Infinispan bit is tagged and released as one and depend on that core tag. That makes for 1 marketing release (website, blog ect). You

Re: [infinispan-dev] [hibernate-dev] [Search] Handling of mutual dependency with Infinispan

I am not sure I understand everything you said. how about you take 20 mins tomorrow during our Hibernate NoORM team meeting on IRC? Be careful, 20 mins run fast in practice :) On 12 May 2014, at 17:38, Sanne Grinovero sa...@hibernate.org wrote: Now that finally Infinispan moved to build (and

[infinispan-dev] OSGi

Hey guys, Sanne and Hardy are working on the OSGi-ification of Hibernate Search and it does not come without trouble. Who is leading this effort on the Infinispan side? I recommend you start early in a release cycle because you will have to butcher APIs and packages to do it properly. Worse,

Re: [infinispan-dev] Infinispan - Hadoop integration

Got it now. That being said, if Alan is correct (one JVM per M/R task run per node), we will need to implement C/S local key and keyset lookup. Emmanuel On 14 Mar 2014, at 12:34, Sanne Grinovero sa...@infinispan.org wrote: On 14 March 2014 09:06, Emmanuel Bernard emman...@hibernate.org wrote

Re: [infinispan-dev] Infinispan - Hadoop integration

and job scheduling/monitoring into different pieces, but I think task execution is the same as MRv1. Thanks, Alan From: Emmanuel Bernard emman...@hibernate.org To: infinispan -Dev List infinispan-dev@lists.jboss.org Sent: Monday, March 17, 2014 11:31:34 AM Subject: Re: [infinispan-dev

Re: [infinispan-dev] Infinispan - Hadoop integration

On 13 mars 2014, at 23:39, Sanne Grinovero sa...@infinispan.org wrote: On 13 March 2014 22:19, Mircea Markus mmar...@redhat.com wrote: On Mar 13, 2014, at 22:17, Sanne Grinovero sa...@infinispan.org wrote: On 13 March 2014 22:05, Mircea Markus mmar...@redhat.com wrote: On Mar 13,

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

when the method cannot determine the size (if allowed by the parameter). Just as easy to check -1 than it is to check null, IMO. On Mar 11, 2014, at 2:21 PM, Emmanuel Bernard emman...@hibernate.org wrote: It does not work, I think, because if you implement your query via some map reduce

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

I agree with Randall. I tend to be very conservative about my public APIs. And offering an API that I think will block me in the future is something I tend to avoid. Something like .guessNbrOfMatchingElements() / .guessResultSize() would provide a better clue about the gamble the user takes.

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

...@infinispan.org wrote: what about we call it int getEstimatedResultSize() ? Having such a method occasionally return null looks very bad to me, I'd rather remove the functionality. -- Sanne On 11 March 2014 19:08, Emmanuel Bernard emman...@hibernate.org wrote: I agree with Randall. I

Re: [infinispan-dev] Design change in Infinispan Query

On 07 Mar 2014, at 16:21, Sanne Grinovero sa...@infinispan.org wrote: Is it possible to use an index for x-cache joins with linear index update time and query? Index update cost is not linear but LogN: approximates to a constant cost. And we could cut this constant by 4 orders of

Re: [infinispan-dev] Design change in Infinispan Query

On Wed 2014-03-05 17:16, Mircea Markus wrote: Sanne came with a good follow up to this email, just some small clarifications: On Mar 4, 2014, at 6:02 PM, Emmanuel Bernard emman...@hibernate.org wrote: If you have to do a map reduce for tasks so simple as age 18, I think you system

Re: [infinispan-dev] Design change in Infinispan Query

On 28 Feb 2014, at 22:14, Mircea Markus mmar...@redhat.com wrote: On Feb 26, 2014, at 5:14 PM, Emmanuel Bernard emman...@hibernate.org wrote: On 25 Feb 2014, at 16:08, Mircea Markus mmar...@redhat.com wrote: On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard emman...@hibernate.org

Re: [infinispan-dev] Design change in Infinispan Query

On 25 Feb 2014, at 16:08, Mircea Markus mmar...@redhat.com wrote: On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard emman...@hibernate.org wrote: On 24 févr. 2014, at 17:39, Mircea Markus mmar...@redhat.com wrote: On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard emman...@hibernate.org

Re: [infinispan-dev] Design change in Infinispan Query

On 24 févr. 2014, at 17:39, Mircea Markus mmar...@redhat.com wrote: On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard emman...@hibernate.org wrote: By the way, Mircea, Sanne and I had quite a long discussion about this one and the idea of one cache per entity. It turns out

Re: [infinispan-dev] Design change in Infinispan Query

On Tue 2014-02-18 14:02, Adrian Nistor wrote: Well, OGM and Infinispan are different species :) So, Infinispan being what it is today - a non-homogenous, schema-less KV store, without support for entity associations (except embedding) - which simplifies the whole thing a lot, should we or

Re: [infinispan-dev] Design change in Infinispan Query

On Tue 2014-02-18 13:27, Sanne Grinovero wrote: On 18 February 2014 13:01, Emmanuel Bernard emman...@hibernate.org wrote: On Tue 2014-02-18 14:02, Adrian Nistor wrote: There were some points raised previously like /if you search for more than one cache transparently, then you probably need

Re: [infinispan-dev] Design change in Infinispan Query

On Mon 2014-02-17 18:43, Galder Zamarreño wrote: On 05 Feb 2014, at 17:30, Emmanuel Bernard emman...@hibernate.org wrote: On Wed 2014-02-05 15:53, Mircea Markus wrote: On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard emman...@hibernate.org wrote: Sure searching for any cache

Re: [infinispan-dev] Design change in Infinispan Query

but it is just cumbersome. On 17 févr. 2014, at 18:51, Emmanuel Bernard emman...@hibernate.org wrote: On Mon 2014-02-17 18:43, Galder Zamarreño wrote: On 05 Feb 2014, at 17:30, Emmanuel Bernard emman...@hibernate.org wrote: On Wed 2014-02-05 15:53, Mircea Markus wrote: On Feb 3, 2014, at 9:32 AM

Re: [infinispan-dev] Remote Query improvements

On Mon 2014-02-10 17:54, Tristan Tarrant wrote: Hi everybody, last week I developed a simple application using Remote Query, and ran into a few issues. Some of them are just technical hurdles, while others have to do with the complexity of the developer experience. Here they are for open

Re: [infinispan-dev] Design change in Infinispan Query

On Wed 2014-02-05 21:40, Mircea Markus wrote: On Feb 5, 2014, at 7:34 PM, Emmanuel Bernard emman...@hibernate.org wrote: On Wed 2014-02-05 17:44, Radim Vansa wrote: On 02/05/2014 05:30 PM, Emmanuel Bernard wrote: On Wed 2014-02-05 15:53, Mircea Markus wrote: On Feb 3, 2014, at 9:32 AM

Re: [infinispan-dev] Design change in Infinispan Query

On Wed 2014-02-05 15:53, Mircea Markus wrote: On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard emman...@hibernate.org wrote: Sure searching for any cache is useful. What I was advocating is that if you search for more than one cache transparently, then you probably need to CRUD for more

Re: [infinispan-dev] Design change in Infinispan Query

On Wed 2014-02-05 17:44, Radim Vansa wrote: On 02/05/2014 05:30 PM, Emmanuel Bernard wrote: On Wed 2014-02-05 15:53, Mircea Markus wrote: On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard emman...@hibernate.org wrote: Sure searching for any cache is useful. What I was advocating

Re: [infinispan-dev] Integration between HotRod and OGM

I'd be curious to see performance tests on Pedro's approach (ie walk through the entire data key set to find the matching elements of a given group). That might be fast enough but that looks quite scary compared to a single lookup. Any doc explaining how FGAM is broken in transactions for

Re: [infinispan-dev] Integration between HotRod and OGM

...@redhat.com wrote: On Nov 19, 2013, at 10:22 AM, Emmanuel Bernard emman...@hibernate.org wrote: It's an interesting approach that would work fine-ish for entities assuming the Hot Rod client is multi threaded and assuming the client uses Future to parallelize the calls. The Java Hotrod

  1   2   >