April 2016 - infinispan-dev - Jboss List Archives

by ugol

Hi guys, I have implemented just get and posts operations at the moment but hopefully with all bells & whistles: - 2.5 protocol - lifespan & expiration as optional parameters with multiple time units - named caches - previous values options - error handling - "full" test suite https://github.com/ugol/infinispan-go/ if you don't see anything blatantly wrong, I can easily complete all L1 hotrod operations, write a bit of documentation and then start the implementation of L2/L3 if you want to test it, just run an 8.2 server and a "go test -v". Sometimes you can see an error due to a race condition in the tests for the message ids, didn't have the time to fix it ciao -- uL Pragmatist http://blog.ugolandini.com http://www.flickr.com/photos/ugol/

9 years, 11 months

2
2
0 / 0

Scattered cache

by Radim Vansa

Hi everyone, in Konstanz I've briefly mentioned alternative distributed 2-owners cache design, now with working title 'Scattered cache'. I've elaborated on this topic on wiki [1] and I would welcome your thoughts about that. Eventually I'd like to do a performance POC (operations without ST implementation). Radim [1] https://github.com/infinispan/infinispan/wiki/Scattered-Cache-design-doc -- Radim Vansa <rvansa(a)redhat.com> JBoss Performance Team

9 years, 11 months

2
1
0 / 0

Remote execute null return (ISPN-6406)

by Galder Zamarreño

Hi all, A Hot Rod protocol change might be required as a result of [1]. In essence, the Hot Rod protocol does not specify how remote exec calls that return null should respond back to the client [2]. Returning an empty byte[] won't cut it since returning an empty String would be represented that way, and that's different to null. I don't know how this could be handled without modifying the protocol, any ideas? If modifying the protocol, adding a new status code would be a way to handle it. Thoughts? [1] https://issues.jboss.org/browse/ISPN-6406 [2] http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_prot... -- Galder Zamarreño Infinispan, Red Hat

9 years, 12 months

3
3
0 / 0

Potential for context object for serial/deserial in marshalling rework

by Galder Zamarreño

Hey guys, Just a quick heads up about [1]. As I was looking at the marshalling code in core, I spotted the work done for [2] and by extension [3]. I can certainly see the practicality of Will's solution in [2] which fitted quite well with the current marshalling architecture, but as we rethink the entire marshalling layer in [1], I'm wondering if a context-object where we can track repeated fields like Strings, Addresses... would be more suitable. For starters, we'd get rid of thread locals and could be more easily exposed in other places. Any ideas or updates you have on the topic please let me know. Cheers, [1] https://issues.jboss.org/browse/ISPN-6498 [2] https://issues.jboss.org/browse/ISPN-4979 [3] https://issues.jboss.org/browse/ISPN-2133 -- Galder Zamarreño Infinispan, Red Hat

9 years, 12 months

4
6
0 / 0

The final part of CDI split

by Sebastian Laskawiec

Hey! In Infinispan 8 series we split CDI into common, remote and embedded. In order to preserve backwards compatibility we decided to leave embedded and common code in "org.infinispan.cdi" package. See [1] for more details. Now in Infinispan 9 I'm planning to move the bits to proper packages as proposed in [2]. Since CDI does most of the job behind the scenes, most of the use cases will preserve backwards compatibility apart from using embedded CDI extension from JBoss Modules. In that case one will need to change his dependency in MANIFEST.MF (or deployment-structure.xml) from "org.infinispan.cdi" to "org.infinispan.cdi.embedded", which is more descriptive in my opinion. Does anyone has any arguments against this change? Thanks Sebastian [1] https://github.com/infinispan/infinispan/pull/4249#issuecomment-211910849 [2] https://github.com/infinispan/infinispan/pull/4249

9 years, 12 months

1
0
0 / 0

Weekly Infinispan IRC Meeting 2016-04-18

by Tristan Tarrant

Hi all, the logs of the weekly meeting are at http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/inf... Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat

9 years, 12 months

1
0
0 / 0

Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net

by Rory O'Donnell

Hi Galder, Early Access b113 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://download.java.net/java/jdk9/changes/jdk-9+113.html>. Early Access b113 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9 with Project Jigsaw is available on java.net. * The important change in this build is that root modules when compiling code in the unnamed module, or when running and the main class is loaded from the class path, do not include the EE modules. More on this in JEP 261. * The other change in this build is that the -Xpatch option is now aligned with what we have documented in JEP 261, support for the old form has been removed. We are very interested in hearing your experiences in testing any Early Access builds. Have you have begun testing against JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered showstopper issues that you would like to discuss? We would really like to hear your findings so far, either reply to me or via the mailing lists [1], [2]. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

10 years

1
0
0 / 0

Distributed Executor remote cancellation

by William Burns

Recently we have been moving a lot of our methods that return Future [1] to CompletableFuture [2]. Unfortunately the latter, CompletableFuture, doesn't allow for cancellation of the future, since there is no thread tied to it. So I am proposing that our DistributedExecutorService [3] no longer allows for interruption of remote threads on a cancellation. This way we can have our distributed executor service return CompletableFuture instances which do not support interruption. Also to note that DistributedExecutorService extends ExecutorService which returns a normal Future which is documented as allowing cancellation. In this case I would just document on DistributedExecutorService that we don't support interruption anyways. Does anyone require the use of interruptable tasks with Distributed Executor? Thanks, - Will [1] https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html [2] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/Completabl... [3] https://docs.jboss.org/infinispan/8.1/apidocs/org/infinispan/distexec/Dis...

10 years

7
11
0 / 0

Should Tree module be deprecated?

by Galder Zamarreño

Re: http://stackoverflow.com/questions/29673123/infinispan-treecache-not-gett... Cheers, -- Galder Zamarreño Infinispan, Red Hat

10 years

4
3
0 / 0

Disabling OSGI on IntelliJ

by Galder Zamarreño

If you need to disable OSGi plugins in IntelliJ, make sure you also disable Osmorc. Somehow this plugin is not found even if you search for 'osgi': https://youtrack.jetbrains.com/issue/IDEA-154323 Cheers, -- Galder Zamarreño Infinispan, Red Hat

10 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-dev April 2016