January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3701) In HotRod client topologyId is shared for all caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3701?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3701: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1029615|https://bugzilla.redhat.com/show_bug.cgi?id=1029615] from VERIFIED to CLOSED > In HotRod client topologyId is shared for all caches > ---------------------------------------------------- > > Key: ISPN-3701 > URL: https://issues.jboss.org/browse/ISPN-3701 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > > The AtomicInteger with topologyId is stored in RemoteCacheManager, therefore, shared for all caches. This can lead to performance problems when accessing two caches with non-synchronized topology ids. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3530: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1029615|https://bugzilla.redhat.com/show_bug.cgi?id=1029615] from VERIFIED to CLOSED > The HotRod client should support a separate CH for each cache > ------------------------------------------------------------- > > Key: ISPN-3530 > URL: https://issues.jboss.org/browse/ISPN-3530 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha5 > > > With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH. > In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4935) Quickstarts: Remote query not working

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4935?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4935: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1159879|https://bugzilla.redhat.com/show_bug.cgi?id=1159879] from VERIFIED to CLOSED > Quickstarts: Remote query not working > ------------------------------------- > > Key: ISPN-4935 > URL: https://issues.jboss.org/browse/ISPN-4935 > Project: Infinispan > Issue Type: Bug > Components: Demos and Tutorials > Affects Versions: 7.0.0.CR2 > Reporter: Jiří Holuša > Assignee: Adrian Nistor > Fix For: 7.1.0.Beta1 > > > When testing remote query quickstarts I found out it's not working anymore. > After setting up the server (as wrote in README file), building it (mvn clean package) and running it (mvn exec:java) I get following exception: > Caused by: java.lang.NoSuchMethodException: org.infinispan.query.remote.ProtobufMetadataManager.registerProtofile([B) > at java.lang.Class.getMethod(Class.java:1665) > at org.infinispan.jmx.ResourceDMBean.invoke(ResourceDMBean.java:268) > I think this is related to https://issues.jboss.org/browse/ISPN-3480 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3701) In HotRod client topologyId is shared for all caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3701?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3701: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1029615|https://bugzilla.redhat.com/show_bug.cgi?id=1029615] from VERIFIED to CLOSED > In HotRod client topologyId is shared for all caches > ---------------------------------------------------- > > Key: ISPN-3701 > URL: https://issues.jboss.org/browse/ISPN-3701 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Galder Zamarreño > > The AtomicInteger with topologyId is stored in RemoteCacheManager, therefore, shared for all caches. This can lead to performance problems when accessing two caches with non-synchronized topology ids. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3530: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1029615|https://bugzilla.redhat.com/show_bug.cgi?id=1029615] from VERIFIED to CLOSED > The HotRod client should support a separate CH for each cache > ------------------------------------------------------------- > > Key: ISPN-3530 > URL: https://issues.jboss.org/browse/ISPN-3530 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha5 > > > With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH. > In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5059: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172038|https://bugzilla.redhat.com/show_bug.cgi?id=1172038] from VERIFIED to CLOSED > JGroups subsystem doesn't support Vault > --------------------------------------- > > Key: ISPN-5059 > URL: https://issues.jboss.org/browse/ISPN-5059 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Affects Versions: 7.0.2.Final > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration: > {noformat} > <protocol type="ENCRYPT"> > <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property> > <property name="store_password">${VAULT::keystore::password::1}</property> > <property name="alias">memcached</property> > </protocol> > {noformat} > i.e. it uses Vault-encrypted password for keystore, it fails with: > {noformat} > groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect > at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55] > Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect > at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309) > at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) > at org.jgroups.JChannel.init(JChannel.java:848) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87) > at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69) > {noformat} > Vault record for {{keystore::password}} exists: > {noformat} > Task: Verify whether a secured attribute exists > Enter Vault Block:keystore > Enter Attribute Name:password > A value exists for (keystore, password) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5059: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172038|https://bugzilla.redhat.com/show_bug.cgi?id=1172038] from VERIFIED to CLOSED > JGroups subsystem doesn't support Vault > --------------------------------------- > > Key: ISPN-5059 > URL: https://issues.jboss.org/browse/ISPN-5059 > Project: Infinispan > Issue Type: Bug > Components: Security, Server > Affects Versions: 7.0.2.Final > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration: > {noformat} > <protocol type="ENCRYPT"> > <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property> > <property name="store_password">${VAULT::keystore::password::1}</property> > <property name="alias">memcached</property> > </protocol> > {noformat} > i.e. it uses Vault-encrypted password for keystore, it fails with: > {noformat} > groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect > at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55] > Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect > at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309) > at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481) > at org.jgroups.JChannel.init(JChannel.java:848) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87) > at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69) > {noformat} > Vault record for {{keystore::password}} exists: > {noformat} > Task: Verify whether a secured attribute exists > Enter Vault Block:keystore > Enter Attribute Name:password > A value exists for (keystore, password) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4499: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1115555|https://bugzilla.redhat.com/show_bug.cgi?id=1115555] from VERIFIED to CLOSED > Prevent shadowing user-defined jgroups configuration file > --------------------------------------------------------- > > Key: ISPN-4499 > URL: https://issues.jboss.org/browse/ISPN-4499 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files. > Proposed solution: > * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution) > * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs) > * when Infinispan is started, log the path to the configuration file used, e.g.: > {code} > 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml' > 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml' > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4884: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from VERIFIED to CLOSED > Deployment scanner should be enabled to allow filter/converter jar deployment > ----------------------------------------------------------------------------- > > Key: ISPN-4884 > URL: https://issues.jboss.org/browse/ISPN-4884 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Final > > > When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built > Steps to Reproduce: > 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/ > 2. look at console output of server > 3. check if there is no output from deployment scanner > Current results: not output from deployment scanner, because it is not enabled > Expected results: we should see following output in console log > JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments > JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4884: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from VERIFIED to CLOSED > Deployment scanner should be enabled to allow filter/converter jar deployment > ----------------------------------------------------------------------------- > > Key: ISPN-4884 > URL: https://issues.jboss.org/browse/ISPN-4884 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 7.0.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.0.0.Final > > > When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built > Steps to Reproduce: > 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/ > 2. look at console output of server > 3. check if there is no output from deployment scanner > Current results: not output from deployment scanner, because it is not enabled > Expected results: we should see following output in console log > JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments > JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar") -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015