From sanne at infinispan.org Mon Feb 1 07:18:56 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Mon, 1 Feb 2016 12:18:56 +0000 Subject: [infinispan-dev] Progress with Java9 testing Message-ID: Hi all, some roadblocks have been solved. Most notably: - ISPN-6090: The Meta-Inf annotation processor which we use was fixed. - WildFly 10 had a problem which would prevent it from booting, version 10.0.0.Final is out now and works fine so integration tests should work fine now (when you upgrade). - ISPN-6085: Avoid using sun.misc.VM The next blocker is: [ERROR] Failed to execute goal org.scala-tools:maven-scala-plugin:2.15.2:script (generate-blueprint) on project infinispan-core: wrap: org.apache.commons.exec.ExecuteException: Process exited with an error: 1(Exit value: 1) -> [Help 1] Could someone of our Scala experts volunteer please? https://jdk9.java.net/download/ Critical dependencies such as JBoss Logger, Hibernate Search, Lucene, already are fully compatible so what are you all waiting for :) I met the OpenJDK team over the weekend at FOSDEM and they reminded once more that they are ready to help and eager to address feedback; but if you all wait for the Final to be shipped to test it that's going to be too late to address some of the changes which are happening. Thanks, Sanne From galder at redhat.com Mon Feb 1 06:46:42 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 1 Feb 2016 12:46:42 +0100 Subject: [infinispan-dev] Tweaking Infinispan Server JGroups stack values Message-ID: <71331D6D-6AFC-4A10-9F04-04C5438B9FDD@redhat.com> Hey Paul/Tristan, Say you have Infinispan Server installed locally, and you want to quickly start an instance with a lower FD_ALL.timeout, GMS.join_timeout, MERGE3.min_interval adn MERGE3.max_interval without touching the XML configuration. Is it possible to do that? Can you pass modified parameters for these options via system properties? I'm not looking to modify them in a particular stack but modifying them all stacks would be fine for me. The context for this is testing topology changes for JS client. Having a cluster started and running tests continously is very convenient for me. With that in mind, a very easy way to test topology changes that does not involve restarting a process is to suspend/resume a process (Node's child processes make this pretty easy to do). My intention is try to tweak the parameters above so that timeouts are lower and hence I can quickly force a topology change. Cheers, -- Galder Zamarre?o Infinispan, Red Hat From slaskawi at redhat.com Mon Feb 1 06:31:33 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Mon, 1 Feb 2016 12:31:33 +0100 Subject: [infinispan-dev] Spring module - change dependencies to Uber Jars Message-ID: Hey! I'm currently trying to solve a tricky class loading issue connected to Spring, CDI and Uber Jars. Here's the scenario: - Remote Uber Jar contains CDI module - Our Hot Rod client use newer version of JBoss Logging which is present in Wildfly/EAP modules - However EAP and Wildfly will load (and make available for deployment) their own version of JBoss Logging [1] - The easiest fix for this is to relocate JBoss Logging package in Uber Jar - Spring module requires some classes from Infinispan Common and they in turn need BasicLogger from JBoss Logging - If we relocate JBoss Logging and will try to use Uber Jar with Spring - we will end up with classloading issue [2] So it seems the best approach is to make Spring depend on Uber Jars instead of "small ones". Of course, users who use small jars will probably be affected by this change (they would have to either accept using Uber Jars or exclude them in their poms and add dependencies manually). Is anyone against this solution? JIRA tracking ticket: [3]. Thanks Sebastian [1] Scenario with Weld enabled WAR https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7 [3] https://issues.jboss.org/browse/ISPN-6132 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160201/63d48f73/attachment.html From sanne at infinispan.org Mon Feb 1 09:12:57 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Mon, 1 Feb 2016 14:12:57 +0000 Subject: [infinispan-dev] Spring module - change dependencies to Uber Jars In-Reply-To: References: Message-ID: The Uber Jars will always be more problematic than the "small ones" - as the testsuite doesn't cover them at the same level, if at all - so I don't think it would be wise to start having components to depend on them, especially as this looks like it might become viral: what about other component X that people will want to use with Spring? Also when you're deploying on WildFly you probably want to use the Logger from the application server as it's the one being managed. So the solution would be wither never use Uber Jars when deploying on the container, or remove JBoss Logger from the Uber Jars. Shall I state once more that the whole Uber Jars affair seems a really bad idea to me? Thanks, Sanne On 1 February 2016 at 11:31, Sebastian Laskawiec wrote: > Hey! > > I'm currently trying to solve a tricky class loading issue connected to > Spring, CDI and Uber Jars. Here's the scenario: > > Remote Uber Jar contains CDI module > Our Hot Rod client use newer version of JBoss Logging which is present in > Wildfly/EAP modules > However EAP and Wildfly will load (and make available for deployment) their > own version of JBoss Logging [1] > > The easiest fix for this is to relocate JBoss Logging package in Uber Jar > > Spring module requires some classes from Infinispan Common and they in turn > need BasicLogger from JBoss Logging > > If we relocate JBoss Logging and will try to use Uber Jar with Spring - we > will end up with classloading issue [2] > > So it seems the best approach is to make Spring depend on Uber Jars instead > of "small ones". Of course, users who use small jars will probably be > affected by this change (they would have to either accept using Uber Jars or > exclude them in their poms and add dependencies manually). > > Is anyone against this solution? JIRA tracking ticket: [3]. > > Thanks > Sebastian > > [1] Scenario with Weld enabled WAR > https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7 > [3] https://issues.jboss.org/browse/ISPN-6132 > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From dan.berindei at gmail.com Mon Feb 1 09:30:01 2016 From: dan.berindei at gmail.com (Dan Berindei) Date: Mon, 1 Feb 2016 16:30:01 +0200 Subject: [infinispan-dev] Infinispan 8.2.0.Beta1 and 8.1.1.Final are out! Message-ID: Dear Infinispan community, We have just released our first release in the 8.2 release cycle, Infinispan 8.2.0.Beta1, and the first bug-fix release for 8.1, 8.1.1.Final. Read all about them here: http://blog.infinispan.org/2016/02/infinispan-820beta1-and-811final-are-out.html Cheers Dan From ttarrant at redhat.com Mon Feb 1 11:09:00 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 1 Feb 2016 17:09:00 +0100 Subject: [infinispan-dev] Weekly IRC Meeting logs 2016-02-01 Message-ID: <56AF831C.1090800@redhat.com> Dear all, the logs for this week's IRC meeting have been collected by the faithful jbott and are available here: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-02-01-15.01.log.html Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From slaskawi at redhat.com Tue Feb 2 01:53:05 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 2 Feb 2016 07:53:05 +0100 Subject: [infinispan-dev] Spring module - change dependencies to Uber Jars In-Reply-To: References: Message-ID: I think the plan is to cover more integration tests (if not all) with Uber Jars - right Martin? WRT the logger - yes you are absolutely correct and that's why logger implementations are excluded from Uber Jars (Ubers contain only APIs - like SLF4J-API or LOG4J-API). I think the uber jar vs small jar is more about what configurations are preferred. Note that you can always (even now) exclude all dependencies from Spring Remote and add Remote Uber Jar manually. Switching Spring Remote module to Uber Jars will only change the default behavior (we will still be able to exclude dependencies and add small jars if you prefer them). If we proceed with this change - of course I will document this excluding part in the docs (currently it is not written anywhere and it is not-so-obvious solution). On Mon, Feb 1, 2016 at 3:12 PM, Sanne Grinovero wrote: > The Uber Jars will always be more problematic than the "small ones" - > as the testsuite doesn't cover them at the same level, if at all - so > I don't think it would be wise to start having components to depend on > them, especially as this looks like it might become viral: what about > other component X that people will want to use with Spring? > > Also when you're deploying on WildFly you probably want to use the > Logger from the application server as it's the one being managed. So > the solution would be wither never use Uber Jars when deploying on the > container, or remove JBoss Logger from the Uber Jars. > > Shall I state once more that the whole Uber Jars affair seems a really > bad idea to me? > > Thanks, > Sanne > > > > On 1 February 2016 at 11:31, Sebastian Laskawiec > wrote: > > Hey! > > > > I'm currently trying to solve a tricky class loading issue connected to > > Spring, CDI and Uber Jars. Here's the scenario: > > > > Remote Uber Jar contains CDI module > > Our Hot Rod client use newer version of JBoss Logging which is present in > > Wildfly/EAP modules > > However EAP and Wildfly will load (and make available for deployment) > their > > own version of JBoss Logging [1] > > > > The easiest fix for this is to relocate JBoss Logging package in Uber Jar > > > > Spring module requires some classes from Infinispan Common and they in > turn > > need BasicLogger from JBoss Logging > > > > If we relocate JBoss Logging and will try to use Uber Jar with Spring - > we > > will end up with classloading issue [2] > > > > So it seems the best approach is to make Spring depend on Uber Jars > instead > > of "small ones". Of course, users who use small jars will probably be > > affected by this change (they would have to either accept using Uber > Jars or > > exclude them in their poms and add dependencies manually). > > > > Is anyone against this solution? JIRA tracking ticket: [3]. > > > > Thanks > > Sebastian > > > > [1] Scenario with Weld enabled WAR > > > https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7 > > [3] https://issues.jboss.org/browse/ISPN-6132 > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160202/6e038eb1/attachment.html From pierrick.hymbert at gmail.com Tue Feb 2 03:19:41 2016 From: pierrick.hymbert at gmail.com (Pierrick HYMBERT) Date: Tue, 2 Feb 2016 11:19:41 +0300 Subject: [infinispan-dev] Got a local cache despite it is configured as distributed Message-ID: Hi all, I am blocked to deploy a test app that use a distributed infinispan (8.0.1) cache within 2 wildfly (10.0.0) domain nodes and a cache entry producer deployed as clustered singleton service. Your feedback/advise are really appreciated! Cache definition: Sample code: @Resource(lookup = "java:jboss/infinispan/container/my-cache-container") private EmbeddedCacheManager cacheContainer; private Cache myAppCache; @PostConstruct public void startNotClustered() throws NamingException { this.myAppCache = this.cacheContainer.getCache("myAppCache"); ... } ... @Schedule(hour = "*", minute = "*", second = "*") public void consume() { logger.info("Cache size on node {} = {}", System.getProperty("jboss.node.name"), myAppCache.size()); } Server one sample logs: 2016-01-31 14:52:03,789 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce new cache entry 1454241123789 on node master:server-one 2016-01-31 14:52:04,005 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache size on node master:server-one = 35 2016-01-31 14:52:04,796 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Produce new cache entry 1454241124796 on node master:server-one 2016-01-31 14:52:05,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache size on node master:server-one = 36 2016-01-31 14:52:05,801 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Produce new cache entry 1454241125801 on node master:server-one 2016-01-31 14:52:06,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache size on node master:server-one = 37 2016-01-31 14:52:06,807 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce new cache entry 1454241126807 on node master:server-one 2016-01-31 14:52:07,005 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache size on node master:server-one = 38 2016-01-31 14:52:07,813 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Produce new cache entry 1454241127813 on node master:server-one 2016-01-31 14:52:08,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache size on node master:server-one = 39 2016-01-31 14:52:08,817 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce new cache entry 1454241128817 on node master:server-one 2016-01-31 14:52:09,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) *Cache size on node master:server-one = 40* Server two logs: 2016-01-31 14:51:56,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache size on node master:server-two = 0 2016-01-31 14:51:57,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache size on node master:server-two = 0 2016-01-31 14:51:58,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache size on node master:server-two = 0 2016-01-31 14:51:59,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Cache size on node master:server-two = 0 2016-01-31 14:52:00,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache size on node master:server-two = 0 2016-01-31 14:52:01,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Cache size on node master:server-two = 0 2016-01-31 14:52:02,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache size on node master:server-two = 0 2016-01-31 14:52:03,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Cache size on node master:server-two = 0 2016-01-31 14:52:04,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache size on node master:server-two = 0 2016-01-31 14:52:05,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Cache size on node master:server-two = 0 2016-01-31 14:52:06,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache size on node master:server-two = 0 2016-01-31 14:52:07,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache size on node master:server-two = 0 2016-01-31 14:52:08,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache size on node master:server-two = 0 2016-01-31 14:52:09,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) *Cache size on node master:server-two = 0* I have attached all necessary info to investigate, but I am not sure attachement is allowed, so you can see source and logs here: https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0 ? ????????? / Cordialement / Best regards, *Pierrick **HYMBERT* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160202/182c803a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: infinispan-issue-wildfly-10.0.0.zip Type: application/zip Size: 64502 bytes Desc: not available Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160202/182c803a/attachment-0001.zip From bban at redhat.com Tue Feb 2 03:30:26 2016 From: bban at redhat.com (Bela Ban) Date: Tue, 02 Feb 2016 09:30:26 +0100 Subject: [infinispan-dev] Tweaking Infinispan Server JGroups stack values In-Reply-To: <71331D6D-6AFC-4A10-9F04-04C5438B9FDD@redhat.com> References: <71331D6D-6AFC-4A10-9F04-04C5438B9FDD@redhat.com> Message-ID: <56B06922.4080704@redhat.com> On 01/02/16 12:46, Galder Zamarre?o wrote: > Hey Paul/Tristan, > > Say you have Infinispan Server installed locally, and you want to > quickly start an instance with a lower FD_ALL.timeout, > GMS.join_timeout, MERGE3.min_interval adn MERGE3.max_interval without > touching the XML configuration. > > Is it possible to do that? Can you pass modified parameters for these > options via system properties? Yes, when you have , you can use -Dmerge3.max_interval=2000 to start. Or, if you want to do this programmatically: JChannel ch; MERGE3 merge3=(MERGE3_ch.getProtocolStack().findProtocol(MERGE3.class); merge3.setMaxInterval(2000); // or merge3.setValue("max_interval", 2000); > I'm not looking to modify them in a particular stack but modifying > them all stacks would be fine for me. > > The context for this is testing topology changes for JS client. > Having a cluster started and running tests continously is very > convenient for me. With that in mind, a very easy way to test > topology changes that does not involve restarting a process is to > suspend/resume a process (Node's child processes make this pretty > easy to do). My intention is try to tweak the parameters above so > that timeouts are lower and hence I can quickly force a topology > change. > > Cheers, -- Galder Zamarre?o Infinispan, Red Hat > > > _______________________________________________ infinispan-dev > mailing list infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) From sanne at infinispan.org Tue Feb 2 09:29:26 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Tue, 2 Feb 2016 14:29:26 +0000 Subject: [infinispan-dev] Got a local cache despite it is configured as distributed In-Reply-To: References: Message-ID: Hi, that's unlikely to be an Infinispan bug as we have many tests and other features relying on it. It probably is a networking configuration problem: if you start multiple servers in a cluster but they do not manage to connect to each other they will start as independent nodes (disconnected from each other) and effectively behave like they were configured in LOCAL mode. I would suggest to check your JGroups stack for it using the network interface that you intended, it using a correct Discovery protocol for your environment, and possibly details like your firewall? On 2 February 2016 at 08:19, Pierrick HYMBERT wrote: > Hi all, > > I am blocked to deploy a test app that use a distributed infinispan (8.0.1) > cache within 2 wildfly (10.0.0) domain nodes and a cache entry producer > deployed as clustered singleton service. > > Your feedback/advise are really appreciated! > > Cache definition: > > > > > > > > > > Sample code: > > @Resource(lookup = "java:jboss/infinispan/container/my-cache-container") > private EmbeddedCacheManager cacheContainer; > > private Cache myAppCache; > > @PostConstruct > public void startNotClustered() throws NamingException { > this.myAppCache = this.cacheContainer.getCache("myAppCache"); > ... > } > > ... > > @Schedule(hour = "*", minute = "*", second = "*") > public void consume() { > logger.info("Cache size on node {} = {}", > System.getProperty("jboss.node.name"), myAppCache.size()); > } > > > Server one sample logs: > 2016-01-31 14:52:03,789 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 1) Produce new cache entry 1454241123789 on node > master:server-one > 2016-01-31 14:52:04,005 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 2) Cache size on node master:server-one = 35 > 2016-01-31 14:52:04,796 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 3) Produce new cache entry 1454241124796 on node > master:server-one > 2016-01-31 14:52:05,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 4) Cache size on node master:server-one = 36 > 2016-01-31 14:52:05,801 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 5) Produce new cache entry 1454241125801 on node > master:server-one > 2016-01-31 14:52:06,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 6) Cache size on node master:server-one = 37 > 2016-01-31 14:52:06,807 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 7) Produce new cache entry 1454241126807 on node > master:server-one > 2016-01-31 14:52:07,005 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 8) Cache size on node master:server-one = 38 > 2016-01-31 14:52:07,813 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 9) Produce new cache entry 1454241127813 on node > master:server-one > 2016-01-31 14:52:08,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 10) Cache size on node master:server-one = 39 > 2016-01-31 14:52:08,817 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 1) Produce new cache entry 1454241128817 on node > master:server-one > 2016-01-31 14:52:09,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 2) Cache size on node master:server-one = 40 > > Server two logs: > 2016-01-31 14:51:56,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 4) Cache size on node master:server-two = 0 > 2016-01-31 14:51:57,008 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 5) Cache size on node master:server-two = 0 > 2016-01-31 14:51:58,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 6) Cache size on node master:server-two = 0 > 2016-01-31 14:51:59,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 7) Cache size on node master:server-two = 0 > 2016-01-31 14:52:00,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 8) Cache size on node master:server-two = 0 > 2016-01-31 14:52:01,008 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 9) Cache size on node master:server-two = 0 > 2016-01-31 14:52:02,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 10) Cache size on node master:server-two = 0 > 2016-01-31 14:52:03,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 1) Cache size on node master:server-two = 0 > 2016-01-31 14:52:04,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 2) Cache size on node master:server-two = 0 > 2016-01-31 14:52:05,008 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 3) Cache size on node master:server-two = 0 > 2016-01-31 14:52:06,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 4) Cache size on node master:server-two = 0 > 2016-01-31 14:52:07,006 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 5) Cache size on node master:server-two = 0 > 2016-01-31 14:52:08,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 6) Cache size on node master:server-two = 0 > 2016-01-31 14:52:09,007 INFO [org.hypik.test.jboss.eap7.server.TestService] > (EJB default - 7) Cache size on node master:server-two = 0 > > > I have attached all necessary info to investigate, but I am not sure > attachement is allowed, so you can see source and logs here: > https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0 > > ? ????????? / Cordialement / Best regards, > > Pierrick HYMBERT > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From gustavo at infinispan.org Wed Feb 3 05:38:50 2016 From: gustavo at infinispan.org (Gustavo Fernandes) Date: Wed, 3 Feb 2016 10:38:50 +0000 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> Message-ID: On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: > Hi all, > > As I write the Javascript client for Hot Rod, and Vittorio writes the C++ > client, the question the encoding of the byte arrays has popped up. > > The reason why encoding matters is mainly because of compatibility mode. > How does a Hot Rod client know how it should transform something a REST > client set? > > To be able to answer this question correctly, the Hot Rod client needs to > know the type of the data. > > Although we could consider adding encoding information to the Hot Rod > protocol long term, in the short term this question might already been > answered by Protostream. > Compatibility between disparate clients should certainly be supported, but what about a pluggable marshaller mechanism? Let's consider all usage scenarios: * Only Java clients: in most cases, JBoss marshalling is adequate, no need to involve protobuf or json and since JBoss Marshalling is default, no need to configure anything. * Mix of Java and C++/C#/Python clients: the Protobuf encoding works wonderfully for that. The client could be configured to use the protostream marshaller, the same for the server. * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] encoding is an interesting option. Same as above, a protostream marshaller with json support could be configured both on client and server. * Custom marshallers: consider FlatBuffers [2], for example, an interesting new cross-platform serializer that allows to access serialized data without de-serializing the whole payload, and without generating any transient memory, and it optionally supports JSON. It could be interesting to write a marshaller based on it and plug it on Infinispan. Although we have a way of configuring the marshaller on client (via RemoteCacheManager) and server (deployable jar), there'd be more work to do in order make them really pluggable: - Some serialization formats like Protobuf and [2] require interface description to be available on both client and server. This is not supported for all marshallers, just for Protostream - Remote query requires some metadata regarding which fields to index and how, and this would need to be possible on every language regardless of the marshalling. Currently, this info can be encoded in the .proto file only, a custom marshaller would not work. - Currently remote query is settled on protobuf not only for the byte array but for the the HotRod query request and response [3] Is having a pluggable serializer mechanism too far fetched, given the effort already invested towards protobuf? Gustavo [1] https://developers.google.com/protocol-buffers/docs/proto3#json [2] https://google.github.io/flatbuffers/ [2] https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ [3] https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160203/0f8e2afe/attachment.html From sanne at infinispan.org Wed Feb 3 06:27:30 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 3 Feb 2016 11:27:30 +0000 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> Message-ID: It sounds like a good idea, almost like a natural evolution, but to play devil's advocate I'll try to find some drawbacks for such a decision. One negative argument is overall complexity: there are many points in code in which one needs to consider that the encoding might be "something else". This isn't a new problem as we already support two modes, but we've soon how much more difficult it makes things and this is making things even a bit more complex. Another point which I don't like much is that people will have to reconfigure the server depending on specific needs of the clients; if we go this way there should be a way in the Hot Rod protocol to "negotiate encoding", so to avoid such configuration tasks for end users (at least when there's no need to actually deploy dependencies on the server to handle some custom encoder..). The other problem I see is that this severely complicates interoperability between different clients. Suppose two applications are being developed to use the Infinispan Server and decide to use two different encoders, I suspect that at some point they'll regret it when needing one to access some data from the other... not suggesting that this should be a good practice, but still it would be very inconvenient. Finally, tooling. We'll eventually need to work on better tooling and supporting multiple encoders would spread efforts thinly. That said, I'm not against the idea of toying with such options and make other encoders as an *experimental* feature: protobuf is the most suited choice but forever is a long time and we should not hinder research on better alternatives. Thanks, Sanne On 3 February 2016 at 10:38, Gustavo Fernandes wrote: > > > On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: >> >> Hi all, >> >> As I write the Javascript client for Hot Rod, and Vittorio writes the C++ >> client, the question the encoding of the byte arrays has popped up. >> >> The reason why encoding matters is mainly because of compatibility mode. >> How does a Hot Rod client know how it should transform something a REST >> client set? >> >> To be able to answer this question correctly, the Hot Rod client needs to >> know the type of the data. >> >> Although we could consider adding encoding information to the Hot Rod >> protocol long term, in the short term this question might already been >> answered by Protostream. > > > > Compatibility between disparate clients should certainly be supported, but > what about a pluggable marshaller mechanism? Let's consider all usage > scenarios: > > * Only Java clients: in most cases, JBoss marshalling is adequate, no need > to involve protobuf or json and since JBoss Marshalling is default, no need > to configure anything. > > * Mix of Java and C++/C#/Python clients: the Protobuf encoding works > wonderfully for that. The client could be configured to use the protostream > marshaller, the same for the server. > > * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] > encoding is an interesting option. Same as above, a protostream marshaller > with json support could > be configured both on client and server. > > * Custom marshallers: consider FlatBuffers [2], for example, an interesting > new cross-platform serializer that allows to access serialized data without > de-serializing the whole payload, > and without generating any transient memory, and it optionally supports > JSON. It could be interesting to write a marshaller based on it and plug it > on Infinispan. > > Although we have a way of configuring the marshaller on client (via > RemoteCacheManager) and server (deployable jar), there'd be more work to do > in order make them really pluggable: > > - Some serialization formats like Protobuf and [2] require interface > description to be available on both client and server. This is not supported > for all marshallers, just for Protostream > - Remote query requires some metadata regarding which fields to index and > how, and this would need to be possible on every language regardless of the > marshalling. > Currently, this info can be encoded in the .proto file only, a custom > marshaller would not work. > - Currently remote query is settled on protobuf not only for the byte array > but for the the HotRod query request and response [3] > > Is having a pluggable serializer mechanism too far fetched, given the effort > already invested towards protobuf? > > Gustavo > > [1] https://developers.google.com/protocol-buffers/docs/proto3#json > [2] https://google.github.io/flatbuffers/ > [2] > https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ > [3] > https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto > >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From sanne at infinispan.org Wed Feb 3 06:34:57 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Wed, 3 Feb 2016 11:34:57 +0000 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> Message-ID: It sounds like a good idea, almost like a natural evolution, but to play devil's advocate I'll try to find some drawbacks for such a decision. One negative argument is overall complexity: there are many points in code in which one needs to consider that the encoding might be "something else". This isn't a new problem as we already support two modes, but we've soon how much more difficult it makes things and this is making things even a bit more complex. Another point which I don't like much is that people will have to reconfigure the server depending on specific needs of the clients; if we go this way there should be a way in the Hot Rod protocol to "negotiate encoding", so to avoid such configuration tasks for end users (at least when there's no need to actually deploy dependencies on the server to handle some custom encoder..). The other problem I see is that this severely complicates interoperability between different clients. Suppose two applications are being developed to use the Infinispan Server and decide to use two different encoders, I suspect that at some point they'll regret it when needing one to access some data from the other... not suggesting that this should be a good practice, but still it would be very inconvenient. Finally, tooling. We'll eventually need to work on better tooling and supporting multiple encoders would spread efforts thinly. That said, I'm not against the idea of toying with such options and make other encoders as an *experimental* feature: protobuf is the most suited choice but forever is a long time and we should not hinder research on better alternatives. Thanks, Sanne On 3 February 2016 at 10:38, Gustavo Fernandes wrote: > > > On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: >> >> Hi all, >> >> As I write the Javascript client for Hot Rod, and Vittorio writes the C++ >> client, the question the encoding of the byte arrays has popped up. >> >> The reason why encoding matters is mainly because of compatibility mode. >> How does a Hot Rod client know how it should transform something a REST >> client set? >> >> To be able to answer this question correctly, the Hot Rod client needs to >> know the type of the data. >> >> Although we could consider adding encoding information to the Hot Rod >> protocol long term, in the short term this question might already been >> answered by Protostream. > > > > Compatibility between disparate clients should certainly be supported, but > what about a pluggable marshaller mechanism? Let's consider all usage > scenarios: > > * Only Java clients: in most cases, JBoss marshalling is adequate, no need > to involve protobuf or json and since JBoss Marshalling is default, no need > to configure anything. > > * Mix of Java and C++/C#/Python clients: the Protobuf encoding works > wonderfully for that. The client could be configured to use the protostream > marshaller, the same for the server. > > * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] > encoding is an interesting option. Same as above, a protostream marshaller > with json support could > be configured both on client and server. > > * Custom marshallers: consider FlatBuffers [2], for example, an interesting > new cross-platform serializer that allows to access serialized data without > de-serializing the whole payload, > and without generating any transient memory, and it optionally supports > JSON. It could be interesting to write a marshaller based on it and plug it > on Infinispan. > > Although we have a way of configuring the marshaller on client (via > RemoteCacheManager) and server (deployable jar), there'd be more work to do > in order make them really pluggable: > > - Some serialization formats like Protobuf and [2] require interface > description to be available on both client and server. This is not supported > for all marshallers, just for Protostream > - Remote query requires some metadata regarding which fields to index and > how, and this would need to be possible on every language regardless of the > marshalling. > Currently, this info can be encoded in the .proto file only, a custom > marshaller would not work. > - Currently remote query is settled on protobuf not only for the byte array > but for the the HotRod query request and response [3] > > Is having a pluggable serializer mechanism too far fetched, given the effort > already invested towards protobuf? > > Gustavo > > [1] https://developers.google.com/protocol-buffers/docs/proto3#json > [2] https://google.github.io/flatbuffers/ > [2] > https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ > [3] > https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto > >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From anistor at redhat.com Wed Feb 3 08:07:24 2016 From: anistor at redhat.com (Adrian Nistor) Date: Wed, 3 Feb 2016 15:07:24 +0200 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> Message-ID: <56B1FB8C.9070500@redhat.com> Hi all, Experimenting with custom marshallers is possible right now. People just loose query support doing so. Freedom has its cost ... (kidding) There are a few simple things we can do right now to better support at least two client categories (and not loose query support) without much changes to current state of the code: 1. provide json support on top of protobuf, via a canonical json <-> protobuf translation. We've been talking about this since ispn 7.x. Meanwhile protobuf3 is out and provides it out of the box, as Gustavo pointed out, so there is even less effort. This would be useful for both REST and hot rod. 2. better support for remote query for java clients using jbossmarshalling (in compat mode only). Would require hibernate-search annotated entities be available on server too, but would spare the user from touching protobuf if he's not interested in interop. The only reason this does not work already is because it was not among the initial set of requirements when designing remote query. 2.5 years later it is clearly a must. Infinispan 9 is not too far, so I propose to implement 1 and 2 as a first step, then see what is the right time frame for the more involved step of decoupling query module's source of metadata form the protobuf schema/marshaller. I think this refactoring deserves to be done even for the sake of elegance and maintainability, if not for plugability. Re Protostream, it is just plain Protobuf folks! It's in no way a customly-modified-encoding-loosely-based-on-protobuf. The only apparent twist is our usage of Protobuf, which btw also follows Google's recommendations (see [1]). All keys and values are wrapped into a struct like this [2] (actually it is a union when looking closer). And for good reason. Adding that metadata as a separate header at hot rod protocol level would be another possibility, but really, having it stored in cache with the key/value is much more appropriate. This type metadata (the type name or type id) is needed for indexing too. And could also be used by some smart cache stores to make some sense out of that blob and map it to database columns or suchlike. And would also be needed by non HR clients, like REST. I can go on .. :) The only downside I see is space. Our caches are not homogeneous, unfortunately [let's not debate now why], so the type info needs to be stored for each single key, value instead of storing it once per cache. Adrian [1] https://developers.google.com/protocol-buffers/docs/techniques#self-description [2] https://raw.githubusercontent.com/anistor/protostream/master/core/src/main/resources/org/infinispan/protostream/message-wrapping.proto On 02/03/2016 01:34 PM, Sanne Grinovero wrote: > It sounds like a good idea, almost like a natural evolution, but to > play devil's advocate I'll try to find some drawbacks for such a > decision. > > One negative argument is overall complexity: there are many points in > code in which one needs to consider that the encoding might be > "something else". This isn't a new problem as we already support two > modes, but we've soon how much more difficult it makes things and this > is making things even a bit more complex. > > Another point which I don't like much is that people will have to > reconfigure the server depending on specific needs of the clients; if > we go this way there should be a way in the Hot Rod protocol to > "negotiate encoding", so to avoid such configuration tasks for end > users (at least when there's no need to actually deploy dependencies > on the server to handle some custom encoder..). > > The other problem I see is that this severely complicates > interoperability between different clients. Suppose two applications > are being developed to use the Infinispan Server and decide to use two > different encoders, I suspect that at some point they'll regret it > when needing one to access some data from the other... not suggesting > that this should be a good practice, but still it would be very > inconvenient. > > Finally, tooling. We'll eventually need to work on better tooling and > supporting multiple encoders would spread efforts thinly. > > That said, I'm not against the idea of toying with such options and > make other encoders as an *experimental* feature: protobuf is the most > suited choice but forever is a long time and we should not hinder > research on better alternatives. > > Thanks, > Sanne > > > > > On 3 February 2016 at 10:38, Gustavo Fernandes wrote: >> >> On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: >>> Hi all, >>> >>> As I write the Javascript client for Hot Rod, and Vittorio writes the C++ >>> client, the question the encoding of the byte arrays has popped up. >>> >>> The reason why encoding matters is mainly because of compatibility mode. >>> How does a Hot Rod client know how it should transform something a REST >>> client set? >>> >>> To be able to answer this question correctly, the Hot Rod client needs to >>> know the type of the data. >>> >>> Although we could consider adding encoding information to the Hot Rod >>> protocol long term, in the short term this question might already been >>> answered by Protostream. >> >> >> Compatibility between disparate clients should certainly be supported, but >> what about a pluggable marshaller mechanism? Let's consider all usage >> scenarios: >> >> * Only Java clients: in most cases, JBoss marshalling is adequate, no need >> to involve protobuf or json and since JBoss Marshalling is default, no need >> to configure anything. >> >> * Mix of Java and C++/C#/Python clients: the Protobuf encoding works >> wonderfully for that. The client could be configured to use the protostream >> marshaller, the same for the server. >> >> * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] >> encoding is an interesting option. Same as above, a protostream marshaller >> with json support could >> be configured both on client and server. >> >> * Custom marshallers: consider FlatBuffers [2], for example, an interesting >> new cross-platform serializer that allows to access serialized data without >> de-serializing the whole payload, >> and without generating any transient memory, and it optionally supports >> JSON. It could be interesting to write a marshaller based on it and plug it >> on Infinispan. >> >> Although we have a way of configuring the marshaller on client (via >> RemoteCacheManager) and server (deployable jar), there'd be more work to do >> in order make them really pluggable: >> >> - Some serialization formats like Protobuf and [2] require interface >> description to be available on both client and server. This is not supported >> for all marshallers, just for Protostream >> - Remote query requires some metadata regarding which fields to index and >> how, and this would need to be possible on every language regardless of the >> marshalling. >> Currently, this info can be encoded in the .proto file only, a custom >> marshaller would not work. >> - Currently remote query is settled on protobuf not only for the byte array >> but for the the HotRod query request and response [3] >> >> Is having a pluggable serializer mechanism too far fetched, given the effort >> already invested towards protobuf? >> >> Gustavo >> >> [1] https://developers.google.com/protocol-buffers/docs/proto3#json >> [2] https://google.github.io/flatbuffers/ >> [2] >> https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ >> [3] >> https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto >> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From gustavo at infinispan.org Wed Feb 3 08:08:01 2016 From: gustavo at infinispan.org (Gustavo Fernandes) Date: Wed, 3 Feb 2016 13:08:01 +0000 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> Message-ID: On Wed, Feb 3, 2016 at 11:27 AM, Sanne Grinovero wrote: > It sounds like a good idea, almost like a natural evolution, but to > play devil's advocate I'll try to find some drawbacks for such a > decision. > > One negative argument is overall complexity: there are many points in > code in which one needs to consider that the encoding might be > "something else". This isn't a new problem as we already support two > modes, but we've soon how much more difficult it makes things and this > is making things even a bit more complex. > Ideally those several points would need to be formalized into an SPI, allowing customizations like it was done for Avro [1] a bit easier maybe. I am not familiar with all those points, but I imagine it'd be a complex refactor nonetheless :) > The other problem I see is that this severely complicates > interoperability between different clients. Suppose two applications > are being developed to use the Infinispan Server and decide to use two > different encoders, I suspect that at some point they'll regret it > when needing one to access some data from the other... not suggesting > that this should be a good practice, but still it would be very > inconvenient. > > I think the issue is the same that happens today: a remote java client using JBoss marshaller wants to start doing queries, it will not work because the server expects Protobuf. > Finally, tooling. We'll eventually need to work on better tooling and > supporting multiple encoders would spread efforts thinly. > I assume you mean tooling to build interface definitions in the case of protobuf or similar? They might already be out there [2][3][4] Gustavo [1] https://github.com/leads-project/infinispan-avro [2] https://code.google.com/p/protobuf-dt/ [3] https://plugins.jetbrains.com/plugin/4942?pr=idea [4] https://plugins.jetbrains.com/plugin/7971?pr=idea -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160203/4202ff91/attachment.html From slaskawi at redhat.com Wed Feb 3 09:11:05 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 3 Feb 2016 15:11:05 +0100 Subject: [infinispan-dev] Spring module - change dependencies to Uber Jars In-Reply-To: References: Message-ID: During our talk on IRC Tristan proposed to mark Spring dependencies as provided. Another similar approach would be to make them optional. I think both approaches are even better than making Spring module depend on Uber Jars. However there is a price to pay - each user will probably have to declare in his pom what dependencies he'd like to use (uber or small jars). On Tue, Feb 2, 2016 at 7:53 AM, Sebastian Laskawiec wrote: > I think the plan is to cover more integration tests (if not all) with Uber > Jars - right Martin? > > WRT the logger - yes you are absolutely correct and that's why logger > implementations are excluded from Uber Jars (Ubers contain only APIs - like > SLF4J-API or LOG4J-API). > > I think the uber jar vs small jar is more about what configurations are > preferred. Note that you can always (even now) exclude all dependencies > from Spring Remote and add Remote Uber Jar manually. Switching Spring > Remote module to Uber Jars will only change the default behavior (we will > still be able to exclude dependencies and add small jars if you prefer > them). > If we proceed with this change - of course I will document this excluding > part in the docs (currently it is not written anywhere and it is > not-so-obvious solution). > > On Mon, Feb 1, 2016 at 3:12 PM, Sanne Grinovero > wrote: > >> The Uber Jars will always be more problematic than the "small ones" - >> as the testsuite doesn't cover them at the same level, if at all - so >> I don't think it would be wise to start having components to depend on >> them, especially as this looks like it might become viral: what about >> other component X that people will want to use with Spring? >> >> Also when you're deploying on WildFly you probably want to use the >> Logger from the application server as it's the one being managed. So >> the solution would be wither never use Uber Jars when deploying on the >> container, or remove JBoss Logger from the Uber Jars. >> >> Shall I state once more that the whole Uber Jars affair seems a really >> bad idea to me? >> >> Thanks, >> Sanne >> >> >> >> On 1 February 2016 at 11:31, Sebastian Laskawiec >> wrote: >> > Hey! >> > >> > I'm currently trying to solve a tricky class loading issue connected to >> > Spring, CDI and Uber Jars. Here's the scenario: >> > >> > Remote Uber Jar contains CDI module >> > Our Hot Rod client use newer version of JBoss Logging which is present >> in >> > Wildfly/EAP modules >> > However EAP and Wildfly will load (and make available for deployment) >> their >> > own version of JBoss Logging [1] >> > >> > The easiest fix for this is to relocate JBoss Logging package in Uber >> Jar >> > >> > Spring module requires some classes from Infinispan Common and they in >> turn >> > need BasicLogger from JBoss Logging >> > >> > If we relocate JBoss Logging and will try to use Uber Jar with Spring - >> we >> > will end up with classloading issue [2] >> > >> > So it seems the best approach is to make Spring depend on Uber Jars >> instead >> > of "small ones". Of course, users who use small jars will probably be >> > affected by this change (they would have to either accept using Uber >> Jars or >> > exclude them in their poms and add dependencies manually). >> > >> > Is anyone against this solution? JIRA tracking ticket: [3]. >> > >> > Thanks >> > Sebastian >> > >> > [1] Scenario with Weld enabled WAR >> > >> https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments >> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7 >> > [3] https://issues.jboss.org/browse/ISPN-6132 >> > >> > _______________________________________________ >> > infinispan-dev mailing list >> > infinispan-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160203/5d41a222/attachment-0001.html From pierrick.hymbert at gmail.com Wed Feb 3 14:11:52 2016 From: pierrick.hymbert at gmail.com (Pierrick HYMBERT) Date: Wed, 03 Feb 2016 19:11:52 +0000 Subject: [infinispan-dev] Got a local cache despite it is configured as distributed In-Reply-To: References: Message-ID: Thanks for your feedback. There is no firewall, server nodes are on the same host, I use default full-ha jgroups config. You can check the code in the link, I also attached domain configuration. I found a workaround by configuring cache definition programatically (that is unexpected, I guess there is an issue in wildfly-clustering-infinispan-extension artifact...): // this.myAppCache = this.cacheContainer.getCache("myAppCache"); this.cacheContainer.defineConfiguration("dist", new ConfigurationBuilder() .clustering() .cacheMode(CacheMode.DIST_SYNC) .hash().numOwners(2) .build() ); this.myAppCache = this.cacheContainer.getCache("dist"); And now it works: 2016-02-02 12:20:25,925 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce new cache entry 1454404825925 on node master:server-one 2016-02-02 12:20:26,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache size on node master:server-one = 172 2016-02-02 12:20:26,009 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache size on node master:server-two = 172 Le mar. 2 f?vr. 2016 17:30, Sanne Grinovero a ?crit : > Hi, > that's unlikely to be an Infinispan bug as we have many tests and > other features relying on it. > It probably is a networking configuration problem: if you start > multiple servers in a cluster but they do not manage to connect to > each other they will start as independent nodes (disconnected from > each other) and effectively behave like they were configured in LOCAL > mode. > > I would suggest to check your JGroups stack for it using the network > interface that you intended, it using a correct Discovery protocol for > your environment, and possibly details like your firewall? > > On 2 February 2016 at 08:19, Pierrick HYMBERT > wrote: > > Hi all, > > > > I am blocked to deploy a test app that use a distributed infinispan > (8.0.1) > > cache within 2 wildfly (10.0.0) domain nodes and a cache entry producer > > deployed as clustered singleton service. > > > > Your feedback/advise are really appreciated! > > > > Cache definition: > > > > > > > > > > > > > > > > > > > > Sample code: > > > > @Resource(lookup = > "java:jboss/infinispan/container/my-cache-container") > > private EmbeddedCacheManager cacheContainer; > > > > private Cache myAppCache; > > > > @PostConstruct > > public void startNotClustered() throws NamingException { > > this.myAppCache = this.cacheContainer.getCache("myAppCache"); > > ... > > } > > > > ... > > > > @Schedule(hour = "*", minute = "*", second = "*") > > public void consume() { > > logger.info("Cache size on node {} = {}", > > System.getProperty("jboss.node.name"), myAppCache.size()); > > } > > > > > > Server one sample logs: > > 2016-01-31 14:52:03,789 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Produce new cache entry 1454241123789 on node > > master:server-one > > 2016-01-31 14:52:04,005 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-one = 35 > > 2016-01-31 14:52:04,796 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 3) Produce new cache entry 1454241124796 on node > > master:server-one > > 2016-01-31 14:52:05,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-one = 36 > > 2016-01-31 14:52:05,801 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Produce new cache entry 1454241125801 on node > > master:server-one > > 2016-01-31 14:52:06,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-one = 37 > > 2016-01-31 14:52:06,807 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Produce new cache entry 1454241126807 on node > > master:server-one > > 2016-01-31 14:52:07,005 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 8) Cache size on node master:server-one = 38 > > 2016-01-31 14:52:07,813 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 9) Produce new cache entry 1454241127813 on node > > master:server-one > > 2016-01-31 14:52:08,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 10) Cache size on node master:server-one = 39 > > 2016-01-31 14:52:08,817 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Produce new cache entry 1454241128817 on node > > master:server-one > > 2016-01-31 14:52:09,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-one = 40 > > > > Server two logs: > > 2016-01-31 14:51:56,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:57,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:58,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:59,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:00,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 8) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:01,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 9) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:02,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 10) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:03,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:04,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:05,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 3) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:06,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:07,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:08,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:09,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Cache size on node master:server-two = 0 > > > > > > I have attached all necessary info to investigate, but I am not sure > > attachement is allowed, so you can see source and logs here: > > > https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0 > > > > ? ????????? / Cordialement / Best regards, > > > > Pierrick HYMBERT > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160203/f86e6d07/attachment.html From ttarrant at redhat.com Wed Feb 3 14:40:33 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 3 Feb 2016 20:40:33 +0100 Subject: [infinispan-dev] Got a local cache despite it is configured as distributed In-Reply-To: References: Message-ID: <56B257B1.9070205@redhat.com> Maybe Paul Ferraro could investigate this further, since he owns the Infinispan subystem in WildFly. Tristan On 03/02/2016 20:11, Pierrick HYMBERT wrote: > Thanks for your feedback. There is no firewall, server nodes are on the > same host, I use default full-ha jgroups config. You can check the code > in the link, I also attached domain configuration. > > I found a workaround by configuring cache definition programatically > (that is unexpected, I guess there is an issue in > wildfly-clustering-infinispan-extension artifact...): > > // this.myAppCache = this.cacheContainer.getCache("myAppCache"); > this.cacheContainer.defineConfiguration("dist", new ConfigurationBuilder() > .clustering() > .cacheMode(CacheMode.DIST_SYNC) > .hash().numOwners(2) > .build() > ); > this.myAppCache = this.cacheContainer.getCache("dist"); > > And now it works: > > 2016-02-02 12:20:25,925 INFO > [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce > new cache entry 1454404825925 on node master:server-one > 2016-02-02 12:20:26,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache > size on node master:server-one = 172 > > 2016-02-02 12:20:26,009 INFO > [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache > size on node master:server-two = 172 > > > Le mar. 2 f?vr. 2016 17:30, Sanne Grinovero > a ?crit : > > Hi, > that's unlikely to be an Infinispan bug as we have many tests and > other features relying on it. > It probably is a networking configuration problem: if you start > multiple servers in a cluster but they do not manage to connect to > each other they will start as independent nodes (disconnected from > each other) and effectively behave like they were configured in LOCAL > mode. > > I would suggest to check your JGroups stack for it using the network > interface that you intended, it using a correct Discovery protocol for > your environment, and possibly details like your firewall? > > On 2 February 2016 at 08:19, Pierrick HYMBERT > > wrote: > > Hi all, > > > > I am blocked to deploy a test app that use a distributed > infinispan (8.0.1) > > cache within 2 wildfly (10.0.0) domain nodes and a cache entry > producer > > deployed as clustered singleton service. > > > > Your feedback/advise are really appreciated! > > > > Cache definition: > > > > > > > > > > > > > > > > > > > > Sample code: > > > > @Resource(lookup = > "java:jboss/infinispan/container/my-cache-container") > > private EmbeddedCacheManager cacheContainer; > > > > private Cache myAppCache; > > > > @PostConstruct > > public void startNotClustered() throws NamingException { > > this.myAppCache = this.cacheContainer.getCache("myAppCache"); > > ... > > } > > > > ... > > > > @Schedule(hour = "*", minute = "*", second = "*") > > public void consume() { > > logger.info ("Cache size on node {} = {}", > > System.getProperty("jboss.node.name > "), myAppCache.size()); > > } > > > > > > Server one sample logs: > > 2016-01-31 14:52:03,789 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Produce new cache entry 1454241123789 on node > > master:server-one > > 2016-01-31 14:52:04,005 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-one = 35 > > 2016-01-31 14:52:04,796 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 3) Produce new cache entry 1454241124796 on node > > master:server-one > > 2016-01-31 14:52:05,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-one = 36 > > 2016-01-31 14:52:05,801 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Produce new cache entry 1454241125801 on node > > master:server-one > > 2016-01-31 14:52:06,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-one = 37 > > 2016-01-31 14:52:06,807 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Produce new cache entry 1454241126807 on node > > master:server-one > > 2016-01-31 14:52:07,005 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 8) Cache size on node master:server-one = 38 > > 2016-01-31 14:52:07,813 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 9) Produce new cache entry 1454241127813 on node > > master:server-one > > 2016-01-31 14:52:08,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 10) Cache size on node master:server-one = 39 > > 2016-01-31 14:52:08,817 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Produce new cache entry 1454241128817 on node > > master:server-one > > 2016-01-31 14:52:09,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-one = 40 > > > > Server two logs: > > 2016-01-31 14:51:56,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:57,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:58,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:59,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:00,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 8) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:01,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 9) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:02,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 10) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:03,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:04,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:05,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 3) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:06,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:07,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:08,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:09,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Cache size on node master:server-two = 0 > > > > > > I have attached all necessary info to investigate, but I am not sure > > attachement is allowed, so you can see source and logs here: > > > https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0 > > > > ? ????????? / Cordialement / Best regards, > > > > Pierrick HYMBERT > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From mgencur at redhat.com Thu Feb 4 09:06:42 2016 From: mgencur at redhat.com (Martin Gencur) Date: Thu, 04 Feb 2016 15:06:42 +0100 Subject: [infinispan-dev] Progress with Java9 testing In-Reply-To: References: Message-ID: <56B35AF2.9080607@redhat.com> On 1.2.2016 13:18, Sanne Grinovero wrote: > [ERROR] Failed to execute goal > org.scala-tools:maven-scala-plugin:2.15.2:script (generate-blueprint) > on project infinispan-core: wrap: > org.apache.commons.exec.ExecuteException: Process exited with an > error: 1(Exit value: 1) -> [Help 1] > > Could someone of our Scala experts volunteer please? I will look into this. Martin From wfink at redhat.com Thu Feb 4 11:35:37 2016 From: wfink at redhat.com (Wolf-Dieter Fink) Date: Thu, 4 Feb 2016 17:35:37 +0100 Subject: [infinispan-dev] Got a local cache despite it is configured as distributed In-Reply-To: References: Message-ID: <56B37DD9.5010404@redhat.com> Hi Pierrick, from what I see you try to use the infinispan subsystem to build your own cache, also your package seems to be planned for EAP7. You should consider that the infinispan subsystem is not meant to have customer caches, there are some restrictions and it is not tested for EAP. I.e. I'm not sure whether the cluster subsystem starts in any case if you use the cache. Note that if you use a subscription for EAP this is not supported! I recommend to use the JDG aka Infinispan modules and configure the cluster for this. - Wolf On 03/02/16 20:11, Pierrick HYMBERT wrote: > Thanks for your feedback. There is no firewall, server nodes are on > the same host, I use default full-ha jgroups config. You can check the > code in the link, I also attached domain configuration. > > I found a workaround by configuring cache definition programatically > (that is unexpected, I guess there is an issue in > wildfly-clustering-infinispan-extension artifact...): > > // this.myAppCache = this.cacheContainer.getCache("myAppCache"); > this.cacheContainer.defineConfiguration("dist", new ConfigurationBuilder() > .clustering() > .cacheMode(CacheMode.DIST_SYNC) > .hash().numOwners(2) > .build() > ); > this.myAppCache = this.cacheContainer.getCache("dist"); > > And now it works: > > 2016-02-02 12:20:25,925 INFO > [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) > Produce new cache entry 1454404825925 on node master:server-one > 2016-02-02 12:20:26,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache > size on node master:server-one = 172 > > 2016-02-02 12:20:26,009 INFO > [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache > size on node master:server-two = 172 > > > Le mar. 2 f?vr. 2016 17:30, Sanne Grinovero > a ?crit : > > Hi, > that's unlikely to be an Infinispan bug as we have many tests and > other features relying on it. > It probably is a networking configuration problem: if you start > multiple servers in a cluster but they do not manage to connect to > each other they will start as independent nodes (disconnected from > each other) and effectively behave like they were configured in LOCAL > mode. > > I would suggest to check your JGroups stack for it using the network > interface that you intended, it using a correct Discovery protocol for > your environment, and possibly details like your firewall? > > On 2 February 2016 at 08:19, Pierrick HYMBERT > > > wrote: > > Hi all, > > > > I am blocked to deploy a test app that use a distributed > infinispan (8.0.1) > > cache within 2 wildfly (10.0.0) domain nodes and a cache entry > producer > > deployed as clustered singleton service. > > > > Your feedback/advise are really appreciated! > > > > Cache definition: > > > > > > > > mode="SYNC"> > > > > > > > > > > > > Sample code: > > > > @Resource(lookup = > "java:jboss/infinispan/container/my-cache-container") > > private EmbeddedCacheManager cacheContainer; > > > > private Cache myAppCache; > > > > @PostConstruct > > public void startNotClustered() throws NamingException { > > this.myAppCache = this.cacheContainer.getCache("myAppCache"); > > ... > > } > > > > ... > > > > @Schedule(hour = "*", minute = "*", second = "*") > > public void consume() { > > logger.info ("Cache size on node {} = {}", > > System.getProperty("jboss.node.name > "), myAppCache.size()); > > } > > > > > > Server one sample logs: > > 2016-01-31 14:52:03,789 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Produce new cache entry 1454241123789 on node > > master:server-one > > 2016-01-31 14:52:04,005 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-one = 35 > > 2016-01-31 14:52:04,796 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 3) Produce new cache entry 1454241124796 on node > > master:server-one > > 2016-01-31 14:52:05,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-one = 36 > > 2016-01-31 14:52:05,801 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Produce new cache entry 1454241125801 on node > > master:server-one > > 2016-01-31 14:52:06,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-one = 37 > > 2016-01-31 14:52:06,807 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Produce new cache entry 1454241126807 on node > > master:server-one > > 2016-01-31 14:52:07,005 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 8) Cache size on node master:server-one = 38 > > 2016-01-31 14:52:07,813 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 9) Produce new cache entry 1454241127813 on node > > master:server-one > > 2016-01-31 14:52:08,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 10) Cache size on node master:server-one = 39 > > 2016-01-31 14:52:08,817 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Produce new cache entry 1454241128817 on node > > master:server-one > > 2016-01-31 14:52:09,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-one = 40 > > > > Server two logs: > > 2016-01-31 14:51:56,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:57,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:58,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-two = 0 > > 2016-01-31 14:51:59,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:00,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 8) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:01,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 9) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:02,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 10) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:03,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 1) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:04,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 2) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:05,008 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 3) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:06,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 4) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:07,006 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 5) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:08,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 6) Cache size on node master:server-two = 0 > > 2016-01-31 14:52:09,007 INFO > [org.hypik.test.jboss.eap7.server.TestService] > > (EJB default - 7) Cache size on node master:server-two = 0 > > > > > > I have attached all necessary info to investigate, but I am not sure > > attachement is allowed, so you can see source and logs here: > > > https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0 > > > > ? ????????? / Cordialement / Best regards, > > > > Pierrick HYMBERT > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160204/3d819e85/attachment.html From rory.odonnell at oracle.com Mon Feb 8 07:47:05 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 8 Feb 2016 12:47:05 +0000 Subject: [infinispan-dev] Early Access builds of JDK 8u76 b04, JDK 9 & JDK 9 with Project Jigsaw b104 are available on java.net Message-ID: <56B88E49.6040004@oracle.com> Hi Galder, Early Access b04 for JDK 8u76 is available on java.net, summary of changes are listed here . Early Access b104 for JDK 9 is available on java.net, summary of changes are listed here . JEP 280: Indify String Concatenation [0] This JEP proposed to change the static |String|-concatenation bytecode sequence generated by |javac| to use |invokedynamic| calls to JDK library functions. This will enable future optimizations of |String| concatenation without requiring further changes to the bytecode emitted by |javac|. Early Access b104 for JDK 9 with Project Jigsaw is available on java.net. Great to meet so many of you at FOSDEM this year, videos of some of the presentations are available [1] Rgds,Rory [0] http://openjdk.java.net/jeps/280 [1] http://video.fosdem.org/2016/h1301 -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160208/01d527df/attachment-0001.html From jholusa at redhat.com Mon Feb 8 10:59:08 2016 From: jholusa at redhat.com (Jiri Holusa) Date: Mon, 8 Feb 2016 10:59:08 -0500 (EST) Subject: [infinispan-dev] Infinispan 8 presentation on DevConf.cz 2016 In-Reply-To: <761888892.15555969.1454946567441.JavaMail.zimbra@redhat.com> Message-ID: <956349635.15560183.1454947148356.JavaMail.zimbra@redhat.com> Hi, I would like to share my presentation [2] that I had on DevConf.cz 2016 [1] this weekend about new features in Infinispan 8. It's based pretty much on Gustavo's presentation (thanks for that), but I also prepared live demo [2] with demonstration of the features. If you would be interested, I could invest some more time in it and make a tutorial or quickstart out of it. Recording of the presentation is available on Youtube [3], the one video contains 5 different presentation being held in the same time, hence you need select the right one :) Cheers, Jiri [1] http://devconf.cz/ [2] https://github.com/Holmistr/DevConfCZ2016Demo [3] https://www.youtube.com/watch?v=RGQxX3edHLw From slaskawi at redhat.com Tue Feb 9 01:40:41 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 9 Feb 2016 07:40:41 +0100 Subject: [infinispan-dev] Infinispan 8 presentation on DevConf.cz 2016 In-Reply-To: <956349635.15560183.1454947148356.JavaMail.zimbra@redhat.com> References: <761888892.15555969.1454946567441.JavaMail.zimbra@redhat.com> <956349635.15560183.1454947148356.JavaMail.zimbra@redhat.com> Message-ID: Hey Jiri! Awesome news! It is always good to see people talking about ISPN! I'm probably blind - but could you tell me how to find your recording? All I can see on the YT link is some Docker stuff.... Thanks Sebastian On Mon, Feb 8, 2016 at 4:59 PM, Jiri Holusa wrote: > Hi, > > I would like to share my presentation [2] that I had on DevConf.cz 2016 > [1] this weekend about new features in Infinispan 8. > It's based pretty much on Gustavo's presentation (thanks for that), but I > also prepared live demo [2] with demonstration of the features. If you > would be interested, I could invest some more time in it and make a > tutorial or quickstart out of it. > > Recording of the presentation is available on Youtube [3], the one video > contains 5 different presentation being held in the same time, hence you > need select the right one :) > > Cheers, > Jiri > > [1] http://devconf.cz/ > [2] https://github.com/Holmistr/DevConfCZ2016Demo > [3] https://www.youtube.com/watch?v=RGQxX3edHLw > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160209/a784b252/attachment.html From vjuranek at redhat.com Tue Feb 9 02:59:45 2016 From: vjuranek at redhat.com (Vojtech Juranek) Date: Tue, 09 Feb 2016 08:59:45 +0100 Subject: [infinispan-dev] Infinispan 8 presentation on DevConf.cz 2016 In-Reply-To: References: <761888892.15555969.1454946567441.JavaMail.zimbra@redhat.com> <956349635.15560183.1454947148356.JavaMail.zimbra@redhat.com> Message-ID: <2201094.oE6FtqIMlI@dhcp-10-40-5-198.brq.redhat.com> Hi Sebastian, > I'm probably blind - but could you tell me how to find your recording? All > I can see on the YT link is some Docker stuff.... for some reason it doesn't work in some browsers well, the direct link to the presentation is [1]. (and another ISPN related DevConf presentation is on [2]) HTH Vojta [1] https://www.youtube.com/watch?v=r0__NEgldzI [2] https://www.youtube.com/watch?v=TVXeXM2g7So -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160209/91ec4d1d/attachment.bin From slaskawi at redhat.com Tue Feb 9 03:19:17 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 9 Feb 2016 09:19:17 +0100 Subject: [infinispan-dev] Infinispan 8 presentation on DevConf.cz 2016 In-Reply-To: <2201094.oE6FtqIMlI@dhcp-10-40-5-198.brq.redhat.com> References: <761888892.15555969.1454946567441.JavaMail.zimbra@redhat.com> <956349635.15560183.1454947148356.JavaMail.zimbra@redhat.com> <2201094.oE6FtqIMlI@dhcp-10-40-5-198.brq.redhat.com> Message-ID: Great work guys! Thanks for the links! On Tue, Feb 9, 2016 at 8:59 AM, Vojtech Juranek wrote: > Hi Sebastian, > > > I'm probably blind - but could you tell me how to find your recording? > All > > I can see on the YT link is some Docker stuff.... > > for some reason it doesn't work in some browsers well, the direct link to > the > presentation is [1]. > (and another ISPN related DevConf presentation is on [2]) > HTH > Vojta > > [1] https://www.youtube.com/watch?v=r0__NEgldzI > [2] https://www.youtube.com/watch?v=TVXeXM2g7So > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160209/3a6852b6/attachment.html From mudokonman at gmail.com Tue Feb 9 11:36:27 2016 From: mudokonman at gmail.com (William Burns) Date: Tue, 09 Feb 2016 16:36:27 +0000 Subject: [infinispan-dev] Lambda Serialization Message-ID: I wanted to propose a pretty simple way of making the lambdas serializable by default that I stumbled upon while working on another issue. I noticed that in the method resolution of the compiler it does some nice things [1]. To be more specific when you have 2 methods with the same name but vary by argument types, it will attempt to pick the most "specific" one. Specific in this case you can think of if I can cast one argument type to the other but it can't be cast to this type, then this one is most specific. Here is an example, given the following class interface SerializableFunction extends Serializable, Function The stream interface already defines: Stream map(Function mapper); But we could add this to the CacheStream interface CacheStream map(SerializableFunction mapper); In this case you have 2 different map methods accessible from your CacheStream instance. When passing a lambda the Java compiler will automatically choose the most specific one (in this case the SerializableFunction one since Function can't be cast to SerializableFunction). This will then make the lambda automatically Serializable. In this way nothing special has to be done (ie. explicit cast) to make the instance Serializable. This allows anyone using our Cache interface to immediately get lambdas that are Serializable when using Streams. The main problem however would be ambiguity because the Serialization would only be applied assuming you are using a defined class of CacheStream etc. Also this means there are 2 methods (but that seems fine to me), so it could cause a bit of confusion. The non serialization method is still helpful if people want to their own Externalizer, since their implementation doesn't have to implement Serializable then. What do you guys think? It seems like a decent compromise to me. - Will [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160209/3130d5d6/attachment.html From mudokonman at gmail.com Tue Feb 9 15:21:02 2016 From: mudokonman at gmail.com (William Burns) Date: Tue, 09 Feb 2016 20:21:02 +0000 Subject: [infinispan-dev] Lambda Serialization In-Reply-To: References: Message-ID: Also I should note that this is not binary compatible since map/filter and other intermediate operations will need to return a CacheStream instead of a Stream as they do currently. This is to make sure the terminal operator when invoked is done upon the CacheStream which defines the Serializable interfaces. This however would be used with [1], which is targeted for 7.2, to allow for much easier way to provide Callable/Runnable instances through lambdas without having to do the ugly casting. [1] https://issues.jboss.org/browse/ISPN-6074 On Tue, Feb 9, 2016 at 11:36 AM William Burns wrote: > I wanted to propose a pretty simple way of making the lambdas serializable > by default that I stumbled upon while working on another issue. > > I noticed that in the method resolution of the compiler it does some nice > things [1]. To be more specific when you have 2 methods with the same name > but vary by argument types, it will attempt to pick the most "specific" > one. Specific in this case you can think of if I can cast one argument > type to the other but it can't be cast to this type, then this one is most > specific. > > Here is an example, given the following class > > interface SerializableFunction extends Serializable, Function > > The stream interface already defines: > > Stream map(Function mapper); > > But we could add this to the CacheStream interface > > CacheStream map(SerializableFunction mapper); > > In this case you have 2 different map methods accessible from your > CacheStream instance. When passing a lambda the Java compiler will > automatically choose the most specific one (in this case the > SerializableFunction one since Function can't be cast to > SerializableFunction). This will then make the lambda automatically > Serializable. In this way nothing special has to be done (ie. explicit > cast) to make the instance Serializable. > > This allows anyone using our Cache interface to immediately get lambdas > that are Serializable when using Streams. > > The main problem however would be ambiguity because the Serialization > would only be applied assuming you are using a defined class of CacheStream > etc. Also this means there are 2 methods (but that seems fine to me), so > it could cause a bit of confusion. The non serialization method is still > helpful if people want to their own Externalizer, since their > implementation doesn't have to implement Serializable then. > > What do you guys think? It seems like a decent compromise to me. > > - Will > > > > > > [1] > https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160209/29e6d15c/attachment-0001.html From mudokonman at gmail.com Tue Feb 9 15:23:18 2016 From: mudokonman at gmail.com (William Burns) Date: Tue, 09 Feb 2016 20:23:18 +0000 Subject: [infinispan-dev] Fwd: Lambda Serialization In-Reply-To: References: Message-ID: Sent that message a bit too soon. Fixed a typo and added 9.0 version for stream methods. ---------- Forwarded message --------- From: William Burns Date: Tue, Feb 9, 2016 at 3:21 PM Subject: Re: Lambda Serialization To: infinispan -Dev List Also I should note that this is not binary compatible since map/filter and other intermediate operations will need to return a CacheStream instead of a Stream as they do currently. This is to make sure the terminal operator when invoked is done upon the CacheStream which defines the Serializable interfaces. Thus it would have to wait until Infinispan 9.0. This however would be used with [1], which is targeted for 8.2, to allow for much easier way to provide Callable/Runnable instances through lambdas without having to do the ugly casting. [1] https://issues.jboss.org/browse/ISPN-6074 On Tue, Feb 9, 2016 at 11:36 AM William Burns wrote: > I wanted to propose a pretty simple way of making the lambdas serializable > by default that I stumbled upon while working on another issue. > > I noticed that in the method resolution of the compiler it does some nice > things [1]. To be more specific when you have 2 methods with the same name > but vary by argument types, it will attempt to pick the most "specific" > one. Specific in this case you can think of if I can cast one argument > type to the other but it can't be cast to this type, then this one is most > specific. > > Here is an example, given the following class > > interface SerializableFunction extends Serializable, Function > > The stream interface already defines: > > Stream map(Function mapper); > > But we could add this to the CacheStream interface > > CacheStream map(SerializableFunction mapper); > > In this case you have 2 different map methods accessible from your > CacheStream instance. When passing a lambda the Java compiler will > automatically choose the most specific one (in this case the > SerializableFunction one since Function can't be cast to > SerializableFunction). This will then make the lambda automatically > Serializable. In this way nothing special has to be done (ie. explicit > cast) to make the instance Serializable. > > This allows anyone using our Cache interface to immediately get lambdas > that are Serializable when using Streams. > > The main problem however would be ambiguity because the Serialization > would only be applied assuming you are using a defined class of CacheStream > etc. Also this means there are 2 methods (but that seems fine to me), so > it could cause a bit of confusion. The non serialization method is still > helpful if people want to their own Externalizer, since their > implementation doesn't have to implement Serializable then. > > What do you guys think? It seems like a decent compromise to me. > > - Will > > > > > > [1] > https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160209/499e7283/attachment.html From ttarrant at redhat.com Wed Feb 10 04:21:06 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 10 Feb 2016 10:21:06 +0100 Subject: [infinispan-dev] Weekly IRC Meeting Log 2016-02-08 Message-ID: <56BB0102.8060006@redhat.com> Dear all, please find the logs for this week's IRC meeting at the following address http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-02-08-15.04.log.html Cheers Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Thu Feb 11 02:27:03 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Thu, 11 Feb 2016 08:27:03 +0100 Subject: [infinispan-dev] Getting ready for 8.2.0.Beta2 Message-ID: <56BC37C7.5040105@redhat.com> Hi all, we will be releasing Beta2 on tuesday, so please please help us shorten the PR queue as soon as possible. Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From rvansa at redhat.com Thu Feb 11 03:24:46 2016 From: rvansa at redhat.com (Radim Vansa) Date: Thu, 11 Feb 2016 09:24:46 +0100 Subject: [infinispan-dev] Getting ready for 8.2.0.Beta2 In-Reply-To: <56BC37C7.5040105@redhat.com> References: <56BC37C7.5040105@redhat.com> Message-ID: <56BC454E.1070000@redhat.com> Is there any way to let github (or the CI, since GH vanilla does not seem to offer that) notify me when PR gets conflicts due to pushes into master, so I need to rebase it? I'd prefer to not enter a situation when I have a waiting PR (I already forgot about), but until someone (thanks, Galder) manually comments 'needs rebase', I have no clue that it's got conflicts. Conflict-free PRs have higher chance to attract reviewer's attention. Radim On 02/11/2016 08:27 AM, Tristan Tarrant wrote: > Hi all, > > we will be releasing Beta2 on tuesday, so please please help us shorten > the PR queue as soon as possible. > > Tristan -- Radim Vansa JBoss Performance Team From sanne at infinispan.org Thu Feb 11 08:15:55 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Thu, 11 Feb 2016 13:15:55 +0000 Subject: [infinispan-dev] Getting ready for 8.2.0.Beta2 In-Reply-To: <56BC37C7.5040105@redhat.com> References: <56BC37C7.5040105@redhat.com> Message-ID: On the indexed Query side, I'd like to merge (and review) the work related to Affinity based Indexing, but this needs an Hibernate Search tag, which can't happen this week. So I hope there will be a Beta3? I'm afraid I won't have time to finish the off-heap index support. I have a clear design in mind but have been waiting for actual coding as it would heavily conflict with the affinity patches.. I'd love if we could get that in 8.2 too. Thanks for the notification BTW, I was having a hard time following the release schedule and some other releases caught me by surprise.. even though I read the IRC meetings logs ;) @Radim: the way I do it is to keep rebasing & re-testing my things until they are merged. Labels help, and if it takes long cherry-pick someone suited and ask them to please merge. On 11 February 2016 at 07:27, Tristan Tarrant wrote: > Hi all, > > we will be releasing Beta2 on tuesday, so please please help us shorten > the PR queue as soon as possible. > > Tristan > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From ttarrant at redhat.com Thu Feb 11 08:26:32 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Thu, 11 Feb 2016 14:26:32 +0100 Subject: [infinispan-dev] Getting ready for 8.2.0.Beta2 In-Reply-To: References: <56BC37C7.5040105@redhat.com> Message-ID: <56BC8C08.5010203@redhat.com> On 11/02/2016 14:15, Sanne Grinovero wrote: > On the indexed Query side, I'd like to merge (and review) the work > related to Affinity based Indexing, > but this needs an Hibernate Search tag, which can't happen this week. > > So I hope there will be a Beta3? Sorry, no time for a Beta3. It will have to be postponed to Infinispan 9... Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From vblagoje at redhat.com Thu Feb 11 14:52:12 2016 From: vblagoje at redhat.com (Vladimir Blagojevic) Date: Thu, 11 Feb 2016 14:52:12 -0500 Subject: [infinispan-dev] Lambda Serialization In-Reply-To: References: Message-ID: <56BCE66C.2040704@redhat.com> I think it does. If we document both approaches nicely *and* give examples then users can choose what suits them the most. Target user group of this API is likely very knowledgeable group of programmers anyway. On 2016-02-09 11:36 AM, William Burns wrote: > I wanted to propose a pretty simple way of making the lambdas > serializable by default that I stumbled upon while working on another > issue. > > I noticed that in the method resolution of the compiler it does some > nice things [1]. To be more specific when you have 2 methods with the > same name but vary by argument types, it will attempt to pick the most > "specific" one. Specific in this case you can think of if I can cast > one argument type to the other but it can't be cast to this type, then > this one is most specific. > > Here is an example, given the following class > > interface SerializableFunction extends Serializable, Function > > The stream interface already defines: > > Stream map(Function mapper); > > But we could add this to the CacheStream interface > > CacheStream map(SerializableFunction mapper); > > In this case you have 2 different map methods accessible from your > CacheStream instance. When passing a lambda the Java compiler will > automatically choose the most specific one (in this case the > SerializableFunction one since Function can't be cast to > SerializableFunction). This will then make the lambda automatically > Serializable. In this way nothing special has to be done (ie. > explicit cast) to make the instance Serializable. > > This allows anyone using our Cache interface to immediately get > lambdas that are Serializable when using Streams. > > The main problem however would be ambiguity because the Serialization > would only be applied assuming you are using a defined class of > CacheStream etc. Also this means there are 2 methods (but that seems > fine to me), so it could cause a bit of confusion. The non > serialization method is still helpful if people want to their own > Externalizer, since their implementation doesn't have to implement > Serializable then. > > What do you guys think? It seems like a decent compromise to me. > > - Will > > > > > > [1] > https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5 > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160211/4974ecf9/attachment-0001.html From sanne at infinispan.org Mon Feb 15 07:46:54 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Mon, 15 Feb 2016 12:46:54 +0000 Subject: [infinispan-dev] Fast codecs for String Message-ID: Chris Vest from Neo4J started this very interesting proposal on the OpenJDK mailing list: http://osdir.com/ml/core-libs-dev/2016-02/msg00277.html Looks like more data-related projects are hitting this bottleneck: AFAIR Netty also uses some workarounds to avoid this. Sanne From slaskawi at redhat.com Tue Feb 16 04:13:58 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Tue, 16 Feb 2016 10:13:58 +0100 Subject: [infinispan-dev] New Ansible-based CI slaves Message-ID: Hey! I'm not sure if you have noticed but we have 3 Ansible slaves now [1]. However there are also bad news :) We use some time thresholds in our CI builds and it will take some time to fill all caches in CI slaves (.m2/repository for example). Please be patient and rerun your jobs if needed. Please let me or Dan know in case of any problems. Thanks Sebastian [1] http://ci.infinispan.org/agents.html?tab=registeredAgents -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160216/4dd053d8/attachment.html From galder at redhat.com Wed Feb 17 03:23:30 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 17 Feb 2016 09:23:30 +0100 Subject: [infinispan-dev] Lambda Serialization In-Reply-To: References: Message-ID: Hey Will, A very interesting discovery! Do you have a branch were you've tried this out? I'd like to play with it to see it in action and analyse the downsides more closely. Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 9 Feb 2016, at 17:36, William Burns wrote: > > I wanted to propose a pretty simple way of making the lambdas serializable by default that I stumbled upon while working on another issue. > > I noticed that in the method resolution of the compiler it does some nice things [1]. To be more specific when you have 2 methods with the same name but vary by argument types, it will attempt to pick the most "specific" one. Specific in this case you can think of if I can cast one argument type to the other but it can't be cast to this type, then this one is most specific. > > Here is an example, given the following class > > interface SerializableFunction extends Serializable, Function > > The stream interface already defines: > > Stream map(Function mapper); > > But we could add this to the CacheStream interface > > CacheStream map(SerializableFunction mapper); > > In this case you have 2 different map methods accessible from your CacheStream instance. When passing a lambda the Java compiler will automatically choose the most specific one (in this case the SerializableFunction one since Function can't be cast to SerializableFunction). This will then make the lambda automatically Serializable. In this way nothing special has to be done (ie. explicit cast) to make the instance Serializable. > > This allows anyone using our Cache interface to immediately get lambdas that are Serializable when using Streams. > > The main problem however would be ambiguity because the Serialization would only be applied assuming you are using a defined class of CacheStream etc. Also this means there are 2 methods (but that seems fine to me), so it could cause a bit of confusion. The non serialization method is still helpful if people want to their own Externalizer, since their implementation doesn't have to implement Serializable then. > > What do you guys think? It seems like a decent compromise to me. > > - Will > > > > > > [1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5 > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From ttarrant at redhat.com Wed Feb 17 04:25:19 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Wed, 17 Feb 2016 10:25:19 +0100 Subject: [infinispan-dev] Weekly IRC Meeting logs 2016-02-17 Message-ID: <56C43C7F.9040302@redhat.com> Dear all, the weekly meeting logs are available at http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-02-15-15.02.log.html Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From galder at redhat.com Wed Feb 17 06:35:05 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 17 Feb 2016 12:35:05 +0100 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> Message-ID: <6CA3CA68-0C75-43BD-A5D3-9CA2E06362D0@redhat.com> I like the idea of pluggable serialization/marshalling, but as you rightly explained, what flexibility gives you you lose by lack of functionality. E.g. querying is only available for protostream based encoding. So, I think we need to remove the hard bind between functionality and encoding to be able to have a trully pluggable encoding mechanism. Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 3 Feb 2016, at 11:38, Gustavo Fernandes wrote: > > > > On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: > Hi all, > > As I write the Javascript client for Hot Rod, and Vittorio writes the C++ client, the question the encoding of the byte arrays has popped up. > > The reason why encoding matters is mainly because of compatibility mode. How does a Hot Rod client know how it should transform something a REST client set? > > To be able to answer this question correctly, the Hot Rod client needs to know the type of the data. > > Although we could consider adding encoding information to the Hot Rod protocol long term, in the short term this question might already been answered by Protostream. > > > Compatibility between disparate clients should certainly be supported, but what about a pluggable marshaller mechanism? Let's consider all usage scenarios: > > * Only Java clients: in most cases, JBoss marshalling is adequate, no need to involve protobuf or json and since JBoss Marshalling is default, no need to configure anything. > > * Mix of Java and C++/C#/Python clients: the Protobuf encoding works wonderfully for that. The client could be configured to use the protostream marshaller, the same for the server. > > * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] encoding is an interesting option. Same as above, a protostream marshaller with json support could > be configured both on client and server. > > * Custom marshallers: consider FlatBuffers [2], for example, an interesting new cross-platform serializer that allows to access serialized data without de-serializing the whole payload, > and without generating any transient memory, and it optionally supports JSON. It could be interesting to write a marshaller based on it and plug it on Infinispan. > > Although we have a way of configuring the marshaller on client (via RemoteCacheManager) and server (deployable jar), there'd be more work to do in order make them really pluggable: > > - Some serialization formats like Protobuf and [2] require interface description to be available on both client and server. This is not supported for all marshallers, just for Protostream > - Remote query requires some metadata regarding which fields to index and how, and this would need to be possible on every language regardless of the marshalling. > Currently, this info can be encoded in the .proto file only, a custom marshaller would not work. > - Currently remote query is settled on protobuf not only for the byte array but for the the HotRod query request and response [3] > > Is having a pluggable serializer mechanism too far fetched, given the effort already invested towards protobuf? > > Gustavo > > [1] https://developers.google.com/protocol-buffers/docs/proto3#json > [2] https://google.github.io/flatbuffers/ > [2] https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ > [3] https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From galder at redhat.com Wed Feb 17 06:48:23 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Wed, 17 Feb 2016 12:48:23 +0100 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: <56B1FB8C.9070500@redhat.com> References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> <56B1FB8C.9070500@redhat.com> Message-ID: <3F7A1950-5BA4-42C4-8720-B23343EE5AD9@redhat.com> > On 3 Feb 2016, at 14:07, Adrian Nistor wrote: > > Hi all, > > > > Re Protostream, it is just plain Protobuf folks! It's in no way a > customly-modified-encoding-loosely-based-on-protobuf. The only apparent > twist is our usage of Protobuf, which btw also follows Google's > recommendations (see [1]). All keys and values are wrapped into a struct > like this [2] (actually it is a union when looking closer). And for good > reason. Adding that metadata as a separate header at hot rod protocol > level would be another possibility, but really, having it stored in > cache with the key/value is much more appropriate. This type metadata > (the type name or type id) is needed for indexing too. And could also be > used by some smart cache stores to make some sense out of that blob and > map it to database columns or suchlike. And would also be needed by non > HR clients, like REST. I can go on .. :) The only downside I see is > space. Our caches are not homogeneous, unfortunately [let's not debate > now why], so the type info needs to be stored for each single key, value > instead of storing it once per cache. ^ I'm not sure Protostream is just plain Protobuf... If you look at [3], you see very specific encoding/decoding steps about the wrapped message. Could I just read Protostream stuff from a JS client with only a .proto file? Looking at [3], it seems like that's not the case and hence I think Protostream imposes certain type of encoding. It looks to me I'd have to encode/decode each basic primitive types manually in the JS client encoder to support Protostream, and only for custom types provided via a .proto file I can delegate to Protobuf itself. @Adrian, am I reading this properly? Cheers, [3] https://github.com/infinispan/protostream/blob/master/core/src/main/java/org/infinispan/protostream/WrappedMessage.java#L54 > > Adrian > > [1] > https://developers.google.com/protocol-buffers/docs/techniques#self-description > [2] > https://raw.githubusercontent.com/anistor/protostream/master/core/src/main/resources/org/infinispan/protostream/message-wrapping.proto > > On 02/03/2016 01:34 PM, Sanne Grinovero wrote: >> It sounds like a good idea, almost like a natural evolution, but to >> play devil's advocate I'll try to find some drawbacks for such a >> decision. >> >> One negative argument is overall complexity: there are many points in >> code in which one needs to consider that the encoding might be >> "something else". This isn't a new problem as we already support two >> modes, but we've soon how much more difficult it makes things and this >> is making things even a bit more complex. >> >> Another point which I don't like much is that people will have to >> reconfigure the server depending on specific needs of the clients; if >> we go this way there should be a way in the Hot Rod protocol to >> "negotiate encoding", so to avoid such configuration tasks for end >> users (at least when there's no need to actually deploy dependencies >> on the server to handle some custom encoder..). >> >> The other problem I see is that this severely complicates >> interoperability between different clients. Suppose two applications >> are being developed to use the Infinispan Server and decide to use two >> different encoders, I suspect that at some point they'll regret it >> when needing one to access some data from the other... not suggesting >> that this should be a good practice, but still it would be very >> inconvenient. >> >> Finally, tooling. We'll eventually need to work on better tooling and >> supporting multiple encoders would spread efforts thinly. >> >> That said, I'm not against the idea of toying with such options and >> make other encoders as an *experimental* feature: protobuf is the most >> suited choice but forever is a long time and we should not hinder >> research on better alternatives. >> >> Thanks, >> Sanne >> >> >> >> >> On 3 February 2016 at 10:38, Gustavo Fernandes wrote: >>> >>> On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: >>>> Hi all, >>>> >>>> As I write the Javascript client for Hot Rod, and Vittorio writes the C++ >>>> client, the question the encoding of the byte arrays has popped up. >>>> >>>> The reason why encoding matters is mainly because of compatibility mode. >>>> How does a Hot Rod client know how it should transform something a REST >>>> client set? >>>> >>>> To be able to answer this question correctly, the Hot Rod client needs to >>>> know the type of the data. >>>> >>>> Although we could consider adding encoding information to the Hot Rod >>>> protocol long term, in the short term this question might already been >>>> answered by Protostream. >>> >>> >>> Compatibility between disparate clients should certainly be supported, but >>> what about a pluggable marshaller mechanism? Let's consider all usage >>> scenarios: >>> >>> * Only Java clients: in most cases, JBoss marshalling is adequate, no need >>> to involve protobuf or json and since JBoss Marshalling is default, no need >>> to configure anything. >>> >>> * Mix of Java and C++/C#/Python clients: the Protobuf encoding works >>> wonderfully for that. The client could be configured to use the protostream >>> marshaller, the same for the server. >>> >>> * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] >>> encoding is an interesting option. Same as above, a protostream marshaller >>> with json support could >>> be configured both on client and server. >>> >>> * Custom marshallers: consider FlatBuffers [2], for example, an interesting >>> new cross-platform serializer that allows to access serialized data without >>> de-serializing the whole payload, >>> and without generating any transient memory, and it optionally supports >>> JSON. It could be interesting to write a marshaller based on it and plug it >>> on Infinispan. >>> >>> Although we have a way of configuring the marshaller on client (via >>> RemoteCacheManager) and server (deployable jar), there'd be more work to do >>> in order make them really pluggable: >>> >>> - Some serialization formats like Protobuf and [2] require interface >>> description to be available on both client and server. This is not supported >>> for all marshallers, just for Protostream >>> - Remote query requires some metadata regarding which fields to index and >>> how, and this would need to be possible on every language regardless of the >>> marshalling. >>> Currently, this info can be encoded in the .proto file only, a custom >>> marshaller would not work. >>> - Currently remote query is settled on protobuf not only for the byte array >>> but for the the HotRod query request and response [3] >>> >>> Is having a pluggable serializer mechanism too far fetched, given the effort >>> already invested towards protobuf? >>> >>> Gustavo >>> >>> [1] https://developers.google.com/protocol-buffers/docs/proto3#json >>> [2] https://google.github.io/flatbuffers/ >>> [2] >>> https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ >>> [3] >>> https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto >>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From mudokonman at gmail.com Wed Feb 17 08:39:21 2016 From: mudokonman at gmail.com (William Burns) Date: Wed, 17 Feb 2016 13:39:21 +0000 Subject: [infinispan-dev] Lambda Serialization In-Reply-To: References: Message-ID: Actually I have a PR that will go in before the 8.2 Final release that uses this [1]. Specifically check out the ClusterExecutor interface. It doesn't have the issues of streams with overloading existing methods, however it adds both overloaded variants and you can see how the tests invoke those. [1] https://github.com/infinispan/infinispan/pull/4008 On Wed, Feb 17, 2016 at 3:23 AM Galder Zamarre?o wrote: > Hey Will, > > A very interesting discovery! > > Do you have a branch were you've tried this out? I'd like to play with it > to see it in action and analyse the downsides more closely. > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > > > On 9 Feb 2016, at 17:36, William Burns wrote: > > > > I wanted to propose a pretty simple way of making the lambdas > serializable by default that I stumbled upon while working on another issue. > > > > I noticed that in the method resolution of the compiler it does some > nice things [1]. To be more specific when you have 2 methods with the same > name but vary by argument types, it will attempt to pick the most > "specific" one. Specific in this case you can think of if I can cast one > argument type to the other but it can't be cast to this type, then this one > is most specific. > > > > Here is an example, given the following class > > > > interface SerializableFunction extends Serializable, Function > > > > The stream interface already defines: > > > > Stream map(Function mapper); > > > > But we could add this to the CacheStream interface > > > > CacheStream map(SerializableFunction mapper); > > > > In this case you have 2 different map methods accessible from your > CacheStream instance. When passing a lambda the Java compiler will > automatically choose the most specific one (in this case the > SerializableFunction one since Function can't be cast to > SerializableFunction). This will then make the lambda automatically > Serializable. In this way nothing special has to be done (ie. explicit > cast) to make the instance Serializable. > > > > This allows anyone using our Cache interface to immediately get lambdas > that are Serializable when using Streams. > > > > The main problem however would be ambiguity because the Serialization > would only be applied assuming you are using a defined class of CacheStream > etc. Also this means there are 2 methods (but that seems fine to me), so > it could cause a bit of confusion. The non serialization method is still > helpful if people want to their own Externalizer, since their > implementation doesn't have to implement Serializable then. > > > > What do you guys think? It seems like a decent compromise to me. > > > > - Will > > > > > > > > > > > > [1] > https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5 > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160217/07850dbc/attachment.html From emmanuel at hibernate.org Wed Feb 17 08:53:36 2016 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Wed, 17 Feb 2016 14:53:36 +0100 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: <6CA3CA68-0C75-43BD-A5D3-9CA2E06362D0@redhat.com> References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> <6CA3CA68-0C75-43BD-A5D3-9CA2E06362D0@redhat.com> Message-ID: <7E1039B3-318F-48C3-8939-FC5E608A69E4@hibernate.org> 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 Zamarre?o wrote: > > I like the idea of pluggable serialization/marshalling, but as you rightly explained, what flexibility gives you you lose by lack of functionality. E.g. querying is only available for protostream based encoding. > > So, I think we need to remove the hard bind between functionality and encoding to be able to have a trully pluggable encoding mechanism. > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 3 Feb 2016, at 11:38, Gustavo Fernandes wrote: >> >> >> >> On Mon, Jan 25, 2016 at 2:03 PM, Galder Zamarre?o wrote: >> Hi all, >> >> As I write the Javascript client for Hot Rod, and Vittorio writes the C++ client, the question the encoding of the byte arrays has popped up. >> >> The reason why encoding matters is mainly because of compatibility mode. How does a Hot Rod client know how it should transform something a REST client set? >> >> To be able to answer this question correctly, the Hot Rod client needs to know the type of the data. >> >> Although we could consider adding encoding information to the Hot Rod protocol long term, in the short term this question might already been answered by Protostream. >> >> >> Compatibility between disparate clients should certainly be supported, but what about a pluggable marshaller mechanism? Let's consider all usage scenarios: >> >> * Only Java clients: in most cases, JBoss marshalling is adequate, no need to involve protobuf or json and since JBoss Marshalling is default, no need to configure anything. >> >> * Mix of Java and C++/C#/Python clients: the Protobuf encoding works wonderfully for that. The client could be configured to use the protostream marshaller, the same for the server. >> >> * Mix of Java, C++/C#/Python and REST clients: protobuf with json [1] encoding is an interesting option. Same as above, a protostream marshaller with json support could >> be configured both on client and server. >> >> * Custom marshallers: consider FlatBuffers [2], for example, an interesting new cross-platform serializer that allows to access serialized data without de-serializing the whole payload, >> and without generating any transient memory, and it optionally supports JSON. It could be interesting to write a marshaller based on it and plug it on Infinispan. >> >> Although we have a way of configuring the marshaller on client (via RemoteCacheManager) and server (deployable jar), there'd be more work to do in order make them really pluggable: >> >> - Some serialization formats like Protobuf and [2] require interface description to be available on both client and server. This is not supported for all marshallers, just for Protostream >> - Remote query requires some metadata regarding which fields to index and how, and this would need to be possible on every language regardless of the marshalling. >> Currently, this info can be encoded in the .proto file only, a custom marshaller would not work. >> - Currently remote query is settled on protobuf not only for the byte array but for the the HotRod query request and response [3] >> >> Is having a pluggable serializer mechanism too far fetched, given the effort already invested towards protobuf? >> >> Gustavo >> >> [1] https://developers.google.com/protocol-buffers/docs/proto3#json >> [2] https://google.github.io/flatbuffers/ >> [2] https://code.facebook.com/posts/872547912839369/improving-facebook-s-performance-on-android-with-flatbuffers/ >> [3] https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From ttarrant at redhat.com Wed Feb 17 19:25:01 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Thu, 18 Feb 2016 01:25:01 +0100 Subject: [infinispan-dev] Infinispan 8.2.0.Beta2 and 8.1.2.Final are out Message-ID: <56C50F5D.5060805@redhat.com> Dear all, we've just released 8.2.0.Beta2 and 8.1.2.Final http://blog.infinispan.org/2016/02/infinispan-820beta2-and-812final.html Enjoy Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From galder at redhat.com Thu Feb 18 06:04:38 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Thu, 18 Feb 2016 12:04:38 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! Message-ID: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> Hi, Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html Cheers, -- Galder Zamarre?o Infinispan, Red Hat From sanne at infinispan.org Thu Feb 18 06:45:09 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Thu, 18 Feb 2016 11:45:09 +0000 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> Message-ID: Congratulations! But I'm surprised by the name shouldn't >npm install infinispan rather be npm install hot-rod ? Or "infinispan-client" ? The current name will teach people that "Infinispan" is the name of a javascript library. On 18 February 2016 at 11:04, Galder Zamarre?o wrote: > Hi, > > Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: > http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From ttarrant at redhat.com Thu Feb 18 08:20:55 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Thu, 18 Feb 2016 14:20:55 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> Message-ID: <56C5C537.80609@redhat.com> Just like all other npm's like mysql, postgresql, cassandra, etc... So while 'infinispan-client' might be more accurate, I don't think 'infinispan' is inherently wrong Tristan On 18/02/2016 12:45, Sanne Grinovero wrote: > Congratulations! > > But I'm surprised by the name shouldn't > >npm install infinispan > > rather be > npm install hot-rod > ? > Or "infinispan-client" ? The current name will teach people that > "Infinispan" is the name of a javascript library. > > On 18 February 2016 at 11:04, Galder Zamarre?o wrote: >> Hi, >> >> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >> >> Cheers, >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From sanne at infinispan.org Thu Feb 18 08:37:52 2016 From: sanne at infinispan.org (Sanne Grinovero) Date: Thu, 18 Feb 2016 13:37:52 +0000 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <56C5C537.80609@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C5C537.80609@redhat.com> Message-ID: Ok, I'm surprised but if that's the common practice in "npm world" I guess we're good. I thought you were proud of the "Hot Rod" brand though :) Thanks, Sanne On 18 February 2016 at 13:20, Tristan Tarrant wrote: > Just like all other npm's like mysql, postgresql, cassandra, etc... > > So while 'infinispan-client' might be more accurate, I don't think > 'infinispan' is inherently wrong > > Tristan > > On 18/02/2016 12:45, Sanne Grinovero wrote: >> Congratulations! >> >> But I'm surprised by the name shouldn't >> >npm install infinispan >> >> rather be >> npm install hot-rod >> ? >> Or "infinispan-client" ? The current name will teach people that >> "Infinispan" is the name of a javascript library. >> >> On 18 February 2016 at 11:04, Galder Zamarre?o wrote: >>> Hi, >>> >>> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >>> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >>> >>> Cheers, >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From mudokonman at gmail.com Thu Feb 18 08:42:46 2016 From: mudokonman at gmail.com (William Burns) Date: Thu, 18 Feb 2016 13:42:46 +0000 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> Message-ID: Awesome, great work! Pretty slick we even support listeners already :) - Will On Thu, Feb 18, 2016 at 6:04 AM Galder Zamarre?o wrote: > Hi, > > Following on Tristan's anouncement, we've also released Infinispan > Javascript client version 0.1.0. You can read all about it here: > > http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160218/438ac3b5/attachment.html From christian at sweazer.com Thu Feb 18 16:00:54 2016 From: christian at sweazer.com (Christian Beikov) Date: Thu, 18 Feb 2016 22:00:54 +0100 Subject: [infinispan-dev] Problems with Wildfly 10 Final Clustering Message-ID: <56C63106.4020003@sweazer.com> Hello, I am having problems with clustering since switching to Wildfly 10 Final and it seems to be related to Infinispan. I am starting a cluster with 2 nodes, the first one starts up, but the second one fails to start with some exceptions about ClassCastExceptions that happen during initial state transfer. Is this a known issue? Maybe a version incompatibility or something? Here is the stacktrace I get: 2016-02-18 14:58:02,093 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 69) MSC000001: Failed to start service jboss.infinispan.ejb.dist: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.dist: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:107) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.start() throws java.lang.Exception on object of type StateTransferManagerImpl at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:218) at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:850) at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:629) at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:580) at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:445) at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:117) at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:112) at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.start(CacheBuilder.java:80) at org.wildfly.clustering.service.AsynchronousServiceBuilder$1.run(AsynchronousServiceBuilder.java:102) ... 4 more Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from f794f53da998, see cause for remote stack trace at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:747) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$80(JGroupsTransport.java:589) at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.futureDone(SingleResponseFuture.java:30) at org.jgroups.blocks.Request.checkCompletion(Request.java:169) at org.jgroups.blocks.UnicastRequest.receiveResponse(UnicastRequest.java:83) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:398) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:684) at org.jgroups.JChannel.up(JChannel.java:738) at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:119) at org.jgroups.stack.Protocol.up(Protocol.java:374) at org.jgroups.protocols.FORK.up(FORK.java:114) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:146) at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) at org.jgroups.protocols.FlowControl.up(FlowControl.java:394) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1045) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064) at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779) at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:652) at org.jgroups.protocols.BARRIER.up(BARRIER.java:152) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) at org.jgroups.protocols.FD.up(FD.java:260) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) at org.jgroups.protocols.Discovery.up(Discovery.java:295) at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) at org.jgroups.protocols.TP$MyHandler.run(TP.java:1796) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.ClassCastException: java.util.concurrent.ConcurrentLinkedDeque cannot be cast to java.util.List at org.infinispan.distribution.ch.impl.DefaultConsistentHash$Externalizer.doReadObject(DefaultConsistentHash.java:378) at org.infinispan.distribution.ch.impl.DefaultConsistentHash$Externalizer.doReadObject(DefaultConsistentHash.java:352) at org.infinispan.commons.marshall.InstanceReusingAdvancedExternalizer.readObject(InstanceReusingAdvancedExternalizer.java:102) at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470) at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231) at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.topology.CacheTopology$Externalizer.doReadObject(CacheTopology.java:201) at org.infinispan.topology.CacheTopology$Externalizer.doReadObject(CacheTopology.java:186) at org.infinispan.commons.marshall.InstanceReusingAdvancedExternalizer.readObject(InstanceReusingAdvancedExternalizer.java:102) at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470) at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231) at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.topology.CacheStatusResponse$Externalizer.readObject(CacheStatusResponse.java:72) at org.infinispan.topology.CacheStatusResponse$Externalizer.readObject(CacheStatusResponse.java:60) at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470) at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231) at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:92) at org.infinispan.remoting.responses.SuccessfulResponse$Externalizer.readObject(SuccessfulResponse.java:77) at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:470) at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:231) at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:149) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:354) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:134) at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101) at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80) at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28) at org.jboss.as.clustering.infinispan.ChannelTransport$1.objectFromBuffer(ChannelTransport.java:57) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390) ... 26 more Regards, Christian From galder at redhat.com Fri Feb 19 03:59:49 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Fri, 19 Feb 2016 09:59:49 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> Message-ID: <55C461D8-9750-4C7D-B613-51F64A4A071F@redhat.com> Memcached client package is called `memcached`, don't see why Infinispan should be any different. I don't think people mistake the Memcached NPM package with the Memcached server :\ Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 18 Feb 2016, at 12:45, Sanne Grinovero wrote: > > Congratulations! > > But I'm surprised by the name shouldn't >> npm install infinispan > > rather be > npm install hot-rod > ? > Or "infinispan-client" ? The current name will teach people that > "Infinispan" is the name of a javascript library. > > On 18 February 2016 at 11:04, Galder Zamarre?o wrote: >> Hi, >> >> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >> >> Cheers, >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Fri Feb 19 04:31:22 2016 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 19 Feb 2016 10:31:22 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> Message-ID: <56C6E0EA.8050305@redhat.com> Just checked the readme, and TBH I wouldn't be too enthusiastic about the deep nesting of chained operations (basically each follow-up operation requires further level of nesting). Is that the way async handlers are usually written in JS? Last few weeks I am working with Gatling and the syntax to describe scenarios = chained operations is quite nice (though it's Scala). Would it be possible to have a syntax like this? connected .then(function(client) { client.put('key', 'value'); .then(function(client) { client.get('key').use(function(value) { console.log(':get(`key`) = ' + value); }).save('p0'); // this would be the same as use(function(value) { client.save('p0') }) }. .then(function(client)) { client.remove('key', client.load('p0')).use(function(success) { console.log(':remove(`key`) = ' + success); }); }).exec(); Note that I've used conditional remove to demonstrate load of previously saved value. Also, I am mixing the concept of client = cache and session, but maybe these could go to single object. Just my 2c Radim On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: > Hi, > > Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: > http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html > > Cheers, > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From rvansa at redhat.com Fri Feb 19 04:37:17 2016 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 19 Feb 2016 10:37:17 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <56C6E0EA.8050305@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C6E0EA.8050305@redhat.com> Message-ID: <56C6E24D.5060900@redhat.com> Err, I've omitted some closing parentheses, but the concept should be clear from indentation. Also, you could omit the declaration of function(client) if you had a static object cache (rather than client here) and cache.put('key', 'value') would return a function doing the put on provided client, rather than executing the operation directly. R. On 02/19/2016 10:31 AM, Radim Vansa wrote: > Just checked the readme, and TBH I wouldn't be too enthusiastic about > the deep nesting of chained operations (basically each follow-up > operation requires further level of nesting). Is that the way async > handlers are usually written in JS? > > Last few weeks I am working with Gatling and the syntax to describe > scenarios = chained operations is quite nice (though it's Scala). Would > it be possible to have a syntax like this? > > connected > .then(function(client) { > client.put('key', 'value'); > .then(function(client) { > client.get('key').use(function(value) { > console.log(':get(`key`) = ' + value); > }).save('p0'); // this would be the same as use(function(value) > { client.save('p0') }) > }. > .then(function(client)) { > client.remove('key', client.load('p0')).use(function(success) { > console.log(':remove(`key`) = ' + success); > }); > }).exec(); > > Note that I've used conditional remove to demonstrate load of previously > saved value. Also, I am mixing the concept of client = cache and > session, but maybe these could go to single object. > > Just my 2c > > Radim > > On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: >> Hi, >> >> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >> >> Cheers, >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Radim Vansa JBoss Performance Team From lthon at redhat.com Fri Feb 19 04:44:51 2016 From: lthon at redhat.com (Ladislav Thon) Date: Fri, 19 Feb 2016 10:44:51 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <56C6E0EA.8050305@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C6E0EA.8050305@redhat.com> Message-ID: <56C6E413.9000909@redhat.com> Inline. > Would it be possible to have a syntax like this? > > connected > .then(function(client) { > client.put('key', 'value'); > .then(function(client) { > client.get('key').use(function(value) { > console.log(':get(`key`) = ' + value); > }).save('p0'); // this would be the same as use(function(value) > { client.save('p0') }) > }. > .then(function(client)) { > client.remove('key', client.load('p0')).use(function(success) { > console.log(':remove(`key`) = ' + success); > }); > }).exec(); JavaScript people have been using promises for quite a while and there's a multitude of opensource implementations. They also made it to ECMAScript 6 [1] and TC39 is even working on async/await (which of course builds on promises) [2]. I would personally claim that using callbacks in JS is no longer acceptable :-), but then, I'm a JS hater, so... [1] http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects [2] https://tc39.github.io/ecmascript-asyncawait/ LT > > Note that I've used conditional remove to demonstrate load of previously > saved value. Also, I am mixing the concept of client = cache and > session, but maybe these could go to single object. > > Just my 2c > > Radim > > On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: >> Hi, >> >> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >> >> Cheers, >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > From galder at redhat.com Fri Feb 19 04:53:27 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Fri, 19 Feb 2016 10:53:27 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <56C6E0EA.8050305@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C6E0EA.8050305@redhat.com> Message-ID: -- Galder Zamarre?o Infinispan, Red Hat > On 19 Feb 2016, at 10:31, Radim Vansa wrote: > > Just checked the readme, and TBH I wouldn't be too enthusiastic about > the deep nesting of chained operations (basically each follow-up > operation requires further level of nesting). Is that the way async > handlers are usually written in JS? I think the README I've produce is a bit confusing, I'll work to improve for future versions. In the mean time, let me explain this: The reason Promises are used instead of callback parameters is precisely to avoid this kind of deep nesting. The code below shows 4 (but could be N really) operations which are chained only 2 levels deep: connected.then(function(client) { ... <- Do something with the client var putCall = client.put('key', 'value'); var getCall = putCall.then(function() { return client.get('key'); }); var containsKeyCall = getCall.then(function() { return client.containsKey('key'); }); var removeCall = containsKeyCall.then(function(contains) { return client.remove('key'); }) }); The key aspect of this is that no matter how many operations you want to chain together, the nesting levels are constant. You could have 100 operations chained together, you would still only have 2 levels deep. The README file might not make this so obvious and hence I'll work to improve on that. Also, the API above is using Promise API which will be standard in ES6. Even though Infinispan JS Client is based on ES5, the `promise` module sticks to the forthcoming standard Promise API, and hence we're using something that in a few years will be standard, which is a good thing. Conceptually, Promise API is similar to Scala's Future or Java's CompletableFuture. The other alternative that's used in Node.js is passing callbacks as parameters to each put/get call... and that does cause very deep nesting, because if you want to chain 100 operations together, you need 100 nested calls! Plus not centralised error handling, and many other disadvantages. > > Last few weeks I am working with Gatling and the syntax to describe > scenarios = chained operations is quite nice (though it's Scala). Would > it be possible to have a syntax like this? > > connected > .then(function(client) { > client.put('key', 'value'); > .then(function(client) { > client.get('key').use(function(value) { > console.log(':get(`key`) = ' + value); > }).save('p0'); // this would be the same as use(function(value) > { client.save('p0') }) > }. > .then(function(client)) { > client.remove('key', client.load('p0')).use(function(success) { > console.log(':remove(`key`) = ' + success); > }); > }).exec(); Independent of the correctness of the syntax, this API can be split in several concepts: 1. The first one is that for those operations that have not a return, e.g. a put, you're passing on the client instance. I think that sounds fine. 2. For your API to work, get() would need to return something other than Promise that has a use/save methods. I'm very reluctant to do anything like that since it's not standard and would require more upfront understanding from the user. Right now, we provide a Promise, a concept that's very well understood in the JS community and that will become standard in ES6. > Note that I've used conditional remove to demonstrate load of previously > saved value. Also, I am mixing the concept of client = cache and > session, but maybe these could go to single object. > > Just my 2c > > Radim > > On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: >> Hi, >> >> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >> >> Cheers, >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Fri Feb 19 05:17:32 2016 From: rvansa at redhat.com (Radim Vansa) Date: Fri, 19 Feb 2016 11:17:32 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C6E0EA.8050305@redhat.com> Message-ID: <56C6EBBC.3080605@redhat.com> All right, this example looks much better. And the ability to use native variables rather than keys into the session is much more comfortable. Thanks for the explanation! Radim On 02/19/2016 10:53 AM, Galder Zamarre?o wrote: > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 19 Feb 2016, at 10:31, Radim Vansa wrote: >> >> Just checked the readme, and TBH I wouldn't be too enthusiastic about >> the deep nesting of chained operations (basically each follow-up >> operation requires further level of nesting). Is that the way async >> handlers are usually written in JS? > I think the README I've produce is a bit confusing, I'll work to improve for future versions. In the mean time, let me explain this: > > The reason Promises are used instead of callback parameters is precisely to avoid this kind of deep nesting. > > The code below shows 4 (but could be N really) operations which are chained only 2 levels deep: > > connected.then(function(client) { > ... <- Do something with the client > var putCall = client.put('key', 'value'); > var getCall = putCall.then(function() { > return client.get('key'); > }); > var containsKeyCall = getCall.then(function() { > return client.containsKey('key'); > }); > var removeCall = containsKeyCall.then(function(contains) { > return client.remove('key'); > }) > }); > > The key aspect of this is that no matter how many operations you want to chain together, the nesting levels are constant. You could have 100 operations chained together, you would still only have 2 levels deep. > > The README file might not make this so obvious and hence I'll work to improve on that. > > Also, the API above is using Promise API which will be standard in ES6. Even though Infinispan JS Client is based on ES5, the `promise` module sticks to the forthcoming standard Promise API, and hence we're using something that in a few years will be standard, which is a good thing. Conceptually, Promise API is similar to Scala's Future or Java's CompletableFuture. > > The other alternative that's used in Node.js is passing callbacks as parameters to each put/get call... and that does cause very deep nesting, because if you want to chain 100 operations together, you need 100 nested calls! Plus not centralised error handling, and many other disadvantages. > >> Last few weeks I am working with Gatling and the syntax to describe >> scenarios = chained operations is quite nice (though it's Scala). Would >> it be possible to have a syntax like this? >> >> connected >> .then(function(client) { >> client.put('key', 'value'); >> .then(function(client) { >> client.get('key').use(function(value) { >> console.log(':get(`key`) = ' + value); >> }).save('p0'); // this would be the same as use(function(value) >> { client.save('p0') }) >> }. >> .then(function(client)) { >> client.remove('key', client.load('p0')).use(function(success) { >> console.log(':remove(`key`) = ' + success); >> }); >> }).exec(); > Independent of the correctness of the syntax, this API can be split in several concepts: > > 1. The first one is that for those operations that have not a return, e.g. a put, you're passing on the client instance. I think that sounds fine. > > 2. For your API to work, get() would need to return something other than Promise that has a use/save methods. I'm very reluctant to do anything like that since it's not standard and would require more upfront understanding from the user. Right now, we provide a Promise, a concept that's very well understood in the JS community and that will become standard in ES6. > >> Note that I've used conditional remove to demonstrate load of previously >> saved value. Also, I am mixing the concept of client = cache and >> session, but maybe these could go to single object. >> >> Just my 2c >> >> Radim >> >> On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: >>> Hi, >>> >>> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >>> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >>> >>> Cheers, >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Radim Vansa >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From ttarrant at redhat.com Mon Feb 22 11:35:40 2016 From: ttarrant at redhat.com (Tristan Tarrant) Date: Mon, 22 Feb 2016 17:35:40 +0100 Subject: [infinispan-dev] Weekly IRC Meeting logs 2016-02-22 Message-ID: <56CB38DC.8040604@redhat.com> Hi all, please find the weekly meeting logs @ http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-02-22-15.01.log.html Tristan -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From galder at redhat.com Tue Feb 23 10:35:45 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Tue, 23 Feb 2016 16:35:45 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: <56C6EBBC.3080605@redhat.com> References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C6E0EA.8050305@redhat.com> <56C6EBBC.3080605@redhat.com> Message-ID: Radim, once again thanks for the invaluable feedback. As promised, I will ammend the README to make it much more clear but I found a very easy example that I can show here as I was working on the JS client testsuite. Imagine this scenario: I want to verify that after doing a put 'stores' statistic goes up by 1. The obvious thing to do here is this: 1. invoke stats to find out initial 'stores' value, then... 2. invoke put, then... 3. invoke stats again and compare with initial 'stores' value. Using Promises, this can be coded in two different ways. The first one is using nesting, e.g. [1]. This is a bit ugly but this is how you'd do have to do it if you were using function callbacks instead of Promises. The alternative is to chain Promises, taking into account that Promise's then() return a Promise or a directly value from within it. Here's an alternative solution that reads more cleanly [2]. Here we can see how the first then() callback returns a value directly, which are the statistics before the put operation. The next two .then() calls return Promises, first a promise for the put, and the second a promise of the stats retrieved after put operation. Finally, we call Promise.all() which takes N promises and calls back .then() when all those promises have been fullfilled, and then passes the results of those promises as parameter. Within this last .then() callback, we can do the necessary assertions compare before and after stastistic values. Hope this clarifies things further. Cheers, p.s. 'stats' operation support is work in progress. [1] https://gist.github.com/galderz/65ed0b2a4e02b8f4e0c1 [2] https://gist.github.com/galderz/c349d3aa64a39684d7d7 -- Galder Zamarre?o Infinispan, Red Hat > On 19 Feb 2016, at 11:17, Radim Vansa wrote: > > All right, this example looks much better. And the ability to use native > variables rather than keys into the session is much more comfortable. > Thanks for the explanation! > > Radim > > On 02/19/2016 10:53 AM, Galder Zamarre?o wrote: >> -- >> Galder Zamarre?o >> Infinispan, Red Hat >> >>> On 19 Feb 2016, at 10:31, Radim Vansa wrote: >>> >>> Just checked the readme, and TBH I wouldn't be too enthusiastic about >>> the deep nesting of chained operations (basically each follow-up >>> operation requires further level of nesting). Is that the way async >>> handlers are usually written in JS? >> I think the README I've produce is a bit confusing, I'll work to improve for future versions. In the mean time, let me explain this: >> >> The reason Promises are used instead of callback parameters is precisely to avoid this kind of deep nesting. >> >> The code below shows 4 (but could be N really) operations which are chained only 2 levels deep: >> >> connected.then(function(client) { >> ... <- Do something with the client >> var putCall = client.put('key', 'value'); >> var getCall = putCall.then(function() { >> return client.get('key'); >> }); >> var containsKeyCall = getCall.then(function() { >> return client.containsKey('key'); >> }); >> var removeCall = containsKeyCall.then(function(contains) { >> return client.remove('key'); >> }) >> }); >> >> The key aspect of this is that no matter how many operations you want to chain together, the nesting levels are constant. You could have 100 operations chained together, you would still only have 2 levels deep. >> >> The README file might not make this so obvious and hence I'll work to improve on that. >> >> Also, the API above is using Promise API which will be standard in ES6. Even though Infinispan JS Client is based on ES5, the `promise` module sticks to the forthcoming standard Promise API, and hence we're using something that in a few years will be standard, which is a good thing. Conceptually, Promise API is similar to Scala's Future or Java's CompletableFuture. >> >> The other alternative that's used in Node.js is passing callbacks as parameters to each put/get call... and that does cause very deep nesting, because if you want to chain 100 operations together, you need 100 nested calls! Plus not centralised error handling, and many other disadvantages. >> >>> Last few weeks I am working with Gatling and the syntax to describe >>> scenarios = chained operations is quite nice (though it's Scala). Would >>> it be possible to have a syntax like this? >>> >>> connected >>> .then(function(client) { >>> client.put('key', 'value'); >>> .then(function(client) { >>> client.get('key').use(function(value) { >>> console.log(':get(`key`) = ' + value); >>> }).save('p0'); // this would be the same as use(function(value) >>> { client.save('p0') }) >>> }. >>> .then(function(client)) { >>> client.remove('key', client.load('p0')).use(function(success) { >>> console.log(':remove(`key`) = ' + success); >>> }); >>> }).exec(); >> Independent of the correctness of the syntax, this API can be split in several concepts: >> >> 1. The first one is that for those operations that have not a return, e.g. a put, you're passing on the client instance. I think that sounds fine. >> >> 2. For your API to work, get() would need to return something other than Promise that has a use/save methods. I'm very reluctant to do anything like that since it's not standard and would require more upfront understanding from the user. Right now, we provide a Promise, a concept that's very well understood in the JS community and that will become standard in ES6. >> >>> Note that I've used conditional remove to demonstrate load of previously >>> saved value. Also, I am mixing the concept of client = cache and >>> session, but maybe these could go to single object. >>> >>> Just my 2c >>> >>> Radim >>> >>> On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: >>>> Hi, >>>> >>>> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >>>> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >>>> >>>> Cheers, >>>> -- >>>> Galder Zamarre?o >>>> Infinispan, Red Hat >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> -- >>> Radim Vansa >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev From rvansa at redhat.com Tue Feb 23 11:27:39 2016 From: rvansa at redhat.com (Radim Vansa) Date: Tue, 23 Feb 2016 17:27:39 +0100 Subject: [infinispan-dev] Infinispan Javascript client 0.1.0 is out now! In-Reply-To: References: <36BD5510-94EC-47BD-AA21-54C459165CD9@redhat.com> <56C6E0EA.8050305@redhat.com> <56C6EBBC.3080605@redhat.com> Message-ID: <56CC887B.4090905@redhat.com> Thanks, though it was pretty clear even after your first reply. One more thing: it seems to me that there is certain redundancy in declaring function(client) { return ... ;} where only the ellipsis is the business logic. I would recommend including helper with higher-order functions, that would give remove the need for the above when you just called ispn API, please see how I've modified var put = before.then(function() { return client.put('k', 'v'); }); // from [2] into var put = before.then(cache().put('k', 'v')); // [3] ([3] includes stub of the helper). Or is this too non-JS-ish (TBH I haven't tested if that is valid JS)? Radim [3] https://gist.github.com/rvansa/ba5be94ba3bf7ae39a91 On 02/23/2016 04:35 PM, Galder Zamarre?o wrote: > Radim, once again thanks for the invaluable feedback. > > As promised, I will ammend the README to make it much more clear but I found a very easy example that I can show here as I was working on the JS client testsuite. > > Imagine this scenario: I want to verify that after doing a put 'stores' statistic goes up by 1. The obvious thing to do here is this: > > 1. invoke stats to find out initial 'stores' value, then... > 2. invoke put, then... > 3. invoke stats again and compare with initial 'stores' value. > > Using Promises, this can be coded in two different ways. The first one is using nesting, e.g. [1]. This is a bit ugly but this is how you'd do have to do it if you were using function callbacks instead of Promises. > > The alternative is to chain Promises, taking into account that Promise's then() return a Promise or a directly value from within it. Here's an alternative solution that reads more cleanly [2]. > > Here we can see how the first then() callback returns a value directly, which are the statistics before the put operation. The next two .then() calls return Promises, first a promise for the put, and the second a promise of the stats retrieved after put operation. > > Finally, we call Promise.all() which takes N promises and calls back .then() when all those promises have been fullfilled, and then passes the results of those promises as parameter. Within this last .then() callback, we can do the necessary assertions compare before and after stastistic values. > > Hope this clarifies things further. > > Cheers, > > p.s. 'stats' operation support is work in progress. > > [1] https://gist.github.com/galderz/65ed0b2a4e02b8f4e0c1 > [2] https://gist.github.com/galderz/c349d3aa64a39684d7d7 > -- > Galder Zamarre?o > Infinispan, Red Hat > >> On 19 Feb 2016, at 11:17, Radim Vansa wrote: >> >> All right, this example looks much better. And the ability to use native >> variables rather than keys into the session is much more comfortable. >> Thanks for the explanation! >> >> Radim >> >> On 02/19/2016 10:53 AM, Galder Zamarre?o wrote: >>> -- >>> Galder Zamarre?o >>> Infinispan, Red Hat >>> >>>> On 19 Feb 2016, at 10:31, Radim Vansa wrote: >>>> >>>> Just checked the readme, and TBH I wouldn't be too enthusiastic about >>>> the deep nesting of chained operations (basically each follow-up >>>> operation requires further level of nesting). Is that the way async >>>> handlers are usually written in JS? >>> I think the README I've produce is a bit confusing, I'll work to improve for future versions. In the mean time, let me explain this: >>> >>> The reason Promises are used instead of callback parameters is precisely to avoid this kind of deep nesting. >>> >>> The code below shows 4 (but could be N really) operations which are chained only 2 levels deep: >>> >>> connected.then(function(client) { >>> ... <- Do something with the client >>> var putCall = client.put('key', 'value'); >>> var getCall = putCall.then(function() { >>> return client.get('key'); >>> }); >>> var containsKeyCall = getCall.then(function() { >>> return client.containsKey('key'); >>> }); >>> var removeCall = containsKeyCall.then(function(contains) { >>> return client.remove('key'); >>> }) >>> }); >>> >>> The key aspect of this is that no matter how many operations you want to chain together, the nesting levels are constant. You could have 100 operations chained together, you would still only have 2 levels deep. >>> >>> The README file might not make this so obvious and hence I'll work to improve on that. >>> >>> Also, the API above is using Promise API which will be standard in ES6. Even though Infinispan JS Client is based on ES5, the `promise` module sticks to the forthcoming standard Promise API, and hence we're using something that in a few years will be standard, which is a good thing. Conceptually, Promise API is similar to Scala's Future or Java's CompletableFuture. >>> >>> The other alternative that's used in Node.js is passing callbacks as parameters to each put/get call... and that does cause very deep nesting, because if you want to chain 100 operations together, you need 100 nested calls! Plus not centralised error handling, and many other disadvantages. >>> >>>> Last few weeks I am working with Gatling and the syntax to describe >>>> scenarios = chained operations is quite nice (though it's Scala). Would >>>> it be possible to have a syntax like this? >>>> >>>> connected >>>> .then(function(client) { >>>> client.put('key', 'value'); >>>> .then(function(client) { >>>> client.get('key').use(function(value) { >>>> console.log(':get(`key`) = ' + value); >>>> }).save('p0'); // this would be the same as use(function(value) >>>> { client.save('p0') }) >>>> }. >>>> .then(function(client)) { >>>> client.remove('key', client.load('p0')).use(function(success) { >>>> console.log(':remove(`key`) = ' + success); >>>> }); >>>> }).exec(); >>> Independent of the correctness of the syntax, this API can be split in several concepts: >>> >>> 1. The first one is that for those operations that have not a return, e.g. a put, you're passing on the client instance. I think that sounds fine. >>> >>> 2. For your API to work, get() would need to return something other than Promise that has a use/save methods. I'm very reluctant to do anything like that since it's not standard and would require more upfront understanding from the user. Right now, we provide a Promise, a concept that's very well understood in the JS community and that will become standard in ES6. >>> >>>> Note that I've used conditional remove to demonstrate load of previously >>>> saved value. Also, I am mixing the concept of client = cache and >>>> session, but maybe these could go to single object. >>>> >>>> Just my 2c >>>> >>>> Radim >>>> >>>> On 02/18/2016 12:04 PM, Galder Zamarre?o wrote: >>>>> Hi, >>>>> >>>>> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here: >>>>> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html >>>>> >>>>> Cheers, >>>>> -- >>>>> Galder Zamarre?o >>>>> Infinispan, Red Hat >>>>> >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> -- >>>> Radim Vansa >>>> JBoss Performance Team >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Radim Vansa >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa JBoss Performance Team From gustavo at infinispan.org Wed Feb 24 05:07:33 2016 From: gustavo at infinispan.org (Gustavo Fernandes) Date: Wed, 24 Feb 2016 10:07:33 +0000 Subject: [infinispan-dev] Hot Rod encoding In-Reply-To: <56B1FB8C.9070500@redhat.com> References: <7164F33B-2C1F-4FCA-8603-525AC2DDE834@redhat.com> <56B1FB8C.9070500@redhat.com> Message-ID: On Wed, Feb 3, 2016 at 1:07 PM, Adrian Nistor wrote: > > 2. better support for remote query for java clients using > jbossmarshalling (in compat mode only). > Would require hibernate-search > annotated entities be available on server too, but would spare the user > from touching protobuf if he's not interested in interop. The only > reason this does not work already is because it was not among the > initial set of requirements when designing remote query. 2.5 years later > it is clearly a must. > Further down the line, we'd probably benefit from having a language neutral way of describing index configuration (analyzers,fields, classes etc). This config would not be tied to hibernate search or any particular marshaller and it could be automatically inferred for java users if they already have hibernate search annotated classes. Having this would allow fulltext capabilities from any language and across marhsallers. WDYT? > Infinispan 9 is not too far, so I propose to implement 1 and 2 as a > first step, then see what is the right time frame for the more involved > step of decoupling query module's source of metadata form the protobuf > schema/marshaller. I think this refactoring deserves to be done even for > the sake of elegance and maintainability, if not for plugability. > +1 > > Re Protostream, it is just plain Protobuf folks! It's in no way a > customly-modified-encoding-loosely-based-on-protobuf. That's clear :) , but looking at the Hot Rod protocol documentation, the Query request itself is encoded in protobuf [1], not only the struct with key/values. Wouldn't it be better to isolate what is marshaller byproduct and what is Hot Rod protocol related? This will make the job of the Hot Rod client implementors easier, and it'd be another step towards a pluggable marshaller. [1] https://github.com/infinispan/infinispan/blob/master/remote-query/remote-query-client/src/main/resources/org/infinispan/query/remote/client/query.proto Gustavo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160224/ca701834/attachment.html From mszynkie at redhat.com Thu Feb 25 07:09:05 2016 From: mszynkie at redhat.com (Michal Szynkiewicz) Date: Thu, 25 Feb 2016 13:09:05 +0100 Subject: [infinispan-dev] Compatibility mode vs TaskContext#getCache Message-ID: Hi, Based on TaskManager used for scripting tasks, I have implemented deployable server (Java) tasks. Having cache configured this way: [1], Anna has written a test which checks if keys and values in the cache need marshalling or not and reported that this doesn't work as expected. After some investigation I found out, that if I acquire cache via cacheManager (e.g. taskContext.getCache().get().getCacheManager().getCache()), the instance operates on proper values (in other words, keys and values don't need marshalling/unmarshalling). In the case of taskContext.getCache().get(), keys and values need to be processed by Marshaller. The cache behind both seems to be the same, a value put in one of them is visible in both. I would really appreciate some tips how to solve it. The test uses RemoteCacheManager#getCache().execute(...) to execute the task. Thanks, Micha? [1] https://github.com/infinispan/infinispan/blob/master/server/integration/testsuite/src/test/resources/config/infinispan/customtask.xml -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160225/89f289db/attachment.html From slaskawi at redhat.com Thu Feb 25 08:43:49 2016 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Thu, 25 Feb 2016 14:43:49 +0100 Subject: [infinispan-dev] Spring module - change dependencies to Uber Jars In-Reply-To: References: Message-ID: Implemented: https://github.com/infinispan/infinispan/pull/4039 Thanks Sebastian On Wed, Feb 3, 2016 at 3:11 PM, Sebastian Laskawiec wrote: > During our talk on IRC Tristan proposed to mark Spring dependencies as > provided. Another similar approach would be to make them optional. > > I think both approaches are even better than making Spring module depend > on Uber Jars. However there is a price to pay - each user will probably > have to declare in his pom what dependencies he'd like to use (uber or > small jars). > > On Tue, Feb 2, 2016 at 7:53 AM, Sebastian Laskawiec > wrote: > >> I think the plan is to cover more integration tests (if not all) with >> Uber Jars - right Martin? >> >> WRT the logger - yes you are absolutely correct and that's why logger >> implementations are excluded from Uber Jars (Ubers contain only APIs - like >> SLF4J-API or LOG4J-API). >> >> I think the uber jar vs small jar is more about what configurations are >> preferred. Note that you can always (even now) exclude all dependencies >> from Spring Remote and add Remote Uber Jar manually. Switching Spring >> Remote module to Uber Jars will only change the default behavior (we will >> still be able to exclude dependencies and add small jars if you prefer >> them). >> If we proceed with this change - of course I will document this excluding >> part in the docs (currently it is not written anywhere and it is >> not-so-obvious solution). >> >> On Mon, Feb 1, 2016 at 3:12 PM, Sanne Grinovero >> wrote: >> >>> The Uber Jars will always be more problematic than the "small ones" - >>> as the testsuite doesn't cover them at the same level, if at all - so >>> I don't think it would be wise to start having components to depend on >>> them, especially as this looks like it might become viral: what about >>> other component X that people will want to use with Spring? >>> >>> Also when you're deploying on WildFly you probably want to use the >>> Logger from the application server as it's the one being managed. So >>> the solution would be wither never use Uber Jars when deploying on the >>> container, or remove JBoss Logger from the Uber Jars. >>> >>> Shall I state once more that the whole Uber Jars affair seems a really >>> bad idea to me? >>> >>> Thanks, >>> Sanne >>> >>> >>> >>> On 1 February 2016 at 11:31, Sebastian Laskawiec >>> wrote: >>> > Hey! >>> > >>> > I'm currently trying to solve a tricky class loading issue connected to >>> > Spring, CDI and Uber Jars. Here's the scenario: >>> > >>> > Remote Uber Jar contains CDI module >>> > Our Hot Rod client use newer version of JBoss Logging which is present >>> in >>> > Wildfly/EAP modules >>> > However EAP and Wildfly will load (and make available for deployment) >>> their >>> > own version of JBoss Logging [1] >>> > >>> > The easiest fix for this is to relocate JBoss Logging package in Uber >>> Jar >>> > >>> > Spring module requires some classes from Infinispan Common and they in >>> turn >>> > need BasicLogger from JBoss Logging >>> > >>> > If we relocate JBoss Logging and will try to use Uber Jar with Spring >>> - we >>> > will end up with classloading issue [2] >>> > >>> > So it seems the best approach is to make Spring depend on Uber Jars >>> instead >>> > of "small ones". Of course, users who use small jars will probably be >>> > affected by this change (they would have to either accept using Uber >>> Jars or >>> > exclude them in their poms and add dependencies manually). >>> > >>> > Is anyone against this solution? JIRA tracking ticket: [3]. >>> > >>> > Thanks >>> > Sebastian >>> > >>> > [1] Scenario with Weld enabled WAR >>> > >>> https://docs.jboss.org/author/display/AS7/Implicit+module+dependencies+for+deployments >>> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7 >>> > [3] https://issues.jboss.org/browse/ISPN-6132 >>> > >>> > _______________________________________________ >>> > infinispan-dev mailing list >>> > infinispan-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160225/64370833/attachment.html From galder at redhat.com Mon Feb 29 05:28:55 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 29 Feb 2016 11:28:55 +0100 Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller Message-ID: <954084CA-04F0-4389-9A09-BB89B7BE8DED@redhat.com> Hi all, While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled. The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good. I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options: - For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO... - An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread... Any other ideas someone might have? Cheers, [1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/hotrod/JBasicMarshaller.h [2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src/main/java/org/jboss/marshalling/river/Protocol.java -- Galder Zamarre?o Infinispan, Red Hat From vrigamon at redhat.com Mon Feb 29 08:35:49 2016 From: vrigamon at redhat.com (Vittorio Rigamonti) Date: Mon, 29 Feb 2016 08:35:49 -0500 (EST) Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller In-Reply-To: <954084CA-04F0-4389-9A09-BB89B7BE8DED@redhat.com> References: <954084CA-04F0-4389-9A09-BB89B7BE8DED@redhat.com> Message-ID: <351961288.55333152.1456752949592.JavaMail.zimbra@redhat.com> Hi All, Hi Galder JBasicMarshaller.h is not an intent to go further along the way to implement a c++ JBossMarshaller, it has the only goal to provide a working 'exec' operation. The c++ exec currently works only with integer and "small" string data types, user can easily extends the marshaller to other basic types. My current model of the exec use case is this one (maybe it's too simplistic so correct me if I'm wrong): a "user defined consumer" consumes data produced by a "user defined producer", so maybe it could worth to evaluate a solution where the framework provides a common standard for communication (stringified json? or JSObject for in memory 100% Java) and let the user handle it's own data. This is a proposal approach specific to the exec scope, I can't say if it can be extended as a general approach where marshalling is involved. Cheers, Vittorio ----- Original Message ----- From: "Galder Zamarre?o" To: "infinispan -Dev List" Sent: Monday, February 29, 2016 11:28:55 AM Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller Hi all, While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled. The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good. I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options: - For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO... - An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread... Any other ideas someone might have? Cheers, [1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/hotrod/JBasicMarshaller.h [2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src/main/java/org/jboss/marshalling/river/Protocol.java -- Galder Zamarre?o Infinispan, Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev From galder at redhat.com Mon Feb 29 13:46:06 2016 From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=) Date: Mon, 29 Feb 2016 19:46:06 +0100 Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller In-Reply-To: <351961288.55333152.1456752949592.JavaMail.zimbra@redhat.com> References: <954084CA-04F0-4389-9A09-BB89B7BE8DED@redhat.com> <351961288.55333152.1456752949592.JavaMail.zimbra@redhat.com> Message-ID: Hi all, I had a chat earlier with Tristan and he pointed me to the metadata information that can be passed in script header. Given that so far (until compatibility is supported), Javascript client only supports String key/values, a very simple solution to this problem would be to define a new metadata parameter, e.g. data-type, which can optionally define the type of key, value, parameters and returned object. E.g. in the javascript client case, I could just say: data-type=utf8 in the header of the script, and that would provide enough hints for the server to do its job by interpreting byte arrays dealt with in exec command as UTF-8 strings. This method is much more user friendly than having user plug a marshaller since it only requires a small change in the header of the script, as opposed to having to change server side configuration. I'm working on a prototype for this with hopes to include in 8.2. Cheers, -- Galder Zamarre?o Infinispan, Red Hat > On 29 Feb 2016, at 14:35, Vittorio Rigamonti wrote: > > Hi All, Hi Galder > > JBasicMarshaller.h is not an intent to go further along the way to implement a c++ JBossMarshaller, it has the only goal to provide a working 'exec' operation. > The c++ exec currently works only with integer and "small" string data types, user can easily extends the marshaller to other basic types. > > My current model of the exec use case is this one (maybe it's too simplistic so correct me if I'm wrong): a "user defined consumer" consumes data produced by a "user defined producer", so maybe it could worth to evaluate a solution where the framework provides a common standard for communication (stringified json? or JSObject for in memory 100% Java) and let the user handle it's own data. > This is a proposal approach specific to the exec scope, I can't say if it can be extended as a general approach where marshalling is involved. > > Cheers, > Vittorio > > > > > ----- Original Message ----- > From: "Galder Zamarre?o" > To: "infinispan -Dev List" > Sent: Monday, February 29, 2016 11:28:55 AM > Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller > > Hi all, > > While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled. > > The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good. > > I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options: > > - For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO... > > - An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread... > > Any other ideas someone might have? > > Cheers, > > [1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/hotrod/JBasicMarshaller.h > [2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src/main/java/org/jboss/marshalling/river/Protocol.java > -- > Galder Zamarre?o > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev