December 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4948) Package embedded CLI as uberjar

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4948?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4948: ---------------------------------- Fix Version/s: 7.1.0.Final 7.0.3.Final > Package embedded CLI as uberjar > ------------------------------- > > Key: ISPN-4948 > URL: https://issues.jboss.org/browse/ISPN-4948 > Project: Infinispan > Issue Type: Feature Request > Components: CLI > Affects Versions: 7.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Alpha1, 7.1.0.Final, 7.0.3.Final > > > The embedded mode CLI depends on a plethora of jars. It can be packaged in a single jar with a proper main class manifest -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

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

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ] Bela Ban commented on ISPN-5059: -------------------------------- {noformat} {${VAULT::keystore::password::1} {noformat} is not a valid variable in JGroups. *If* this is evaluated by JGroups, then JGroups thinks the variable name is VAULT and the default value :keystore::password::1. Are the double colons needed ? > 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 > Reporter: Vojtech Juranek > > 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.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5017) Include the CLI uberjar in the distribution zip

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5017?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5017: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.1.0.Beta1 7.1.0.Final Resolution: Done > Include the CLI uberjar in the distribution zip > ----------------------------------------------- > > Key: ISPN-5017 > URL: https://issues.jboss.org/browse/ISPN-5017 > Project: Infinispan > Issue Type: Feature Request > Reporter: Ion Savin > Assignee: Ion Savin > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > Add the uberjar in all/cli to the distribution zip. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5067) CLI for server docs need updating to reflect WildFly base

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5067: ------------------------------------- Summary: CLI for server docs need updating to reflect WildFly base Key: ISPN-5067 URL: https://issues.jboss.org/browse/ISPN-5067 Project: Infinispan Issue Type: Bug Components: Documentation-Servers Affects Versions: 7.1.0.Alpha1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.1.0.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5010) Improve remote listener performance

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5010?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5010: ---------------------------------------- Another enhancement: * Default client events only ship key and version information. However, without an explicit converter, clustered events received server side would contain value information even though this is not used at all by the clustered listener implementation. So, install a default converter for default events that only ships key and version information. > Improve remote listener performance > ----------------------------------- > > Key: ISPN-5010 > URL: https://issues.jboss.org/browse/ISPN-5010 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this: > * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained. > * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients. > * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. (see ISPN-4491) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5010) Improve remote listener performance

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5010?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5010: ----------------------------------- Description: We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this: * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained. * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients. * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. (see ISPN-4491) was: We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this: * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained. * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients. * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. > Improve remote listener performance > ----------------------------------- > > Key: ISPN-5010 > URL: https://issues.jboss.org/browse/ISPN-5010 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Beta1, 7.1.0.Final > > > We've run some performance tests and we've noticed remote listeners have a too negative effect on get/put/remove operations, particularly as number of listeners added by clients increase. This JIRA encompasses different pieces of work to improve this: > * Make server-side clustered listener async. By doing so, the operations are detached from the actual server-side listener part when the notification is sent to clients. Async listener executor is configured with 1 thread, so order is still maintained. > * Batching at the server-side clustered listener side. Instead of sending each event as it comes, apply time/size based batching to reduce number of system calls to flush sockets to clients. > * Further improvements might come from bundling listeners added by same client, but this is more complicated to achieve, since only those listeners that have similar characteristics can be bundled, e.g. have same filter/converter settings. Also, whether to use a single connection for all listeners or maintain separate ones still would need to be decided. (see ISPN-4491) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5029) Infinispan 7.0.2 not fully backwards compatible with 6.0.x

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5029?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-5029. ----------------------------------- Resolution: Done > Infinispan 7.0.2 not fully backwards compatible with 6.0.x > ---------------------------------------------------------- > > Key: ISPN-5029 > URL: https://issues.jboss.org/browse/ISPN-5029 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 7.1.0.Beta1, 7.1.0.Final, 7.0.3.Final > > > Using Hibernate 4.3.x with Infinispan 7 throws: > {code} > Caused by: java.lang.IncompatibleClassChangeError: Found class org.infinispan.commons.util.FileLookup, but interface was expected > at org.hibernate.cache.infinispan.InfinispanRegionFactory.createCacheManager(InfinispanRegionFactory.java:406) > at org.hibernate.cache.infinispan.InfinispanRegionFactory.start(InfinispanRegionFactory.java:323) > ... 141 more > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-5035: ----------------------------------- But I understand that DeltaAware API may not be the best tool - it's simply limited. Let's focus this JIRA on the aspect that it is not supported in ReplaceCommand, rather than that it returns always the full value. > DeltaAware support for conditional operations > --------------------------------------------- > > Key: ISPN-5035 > URL: https://issues.jboss.org/browse/ISPN-5035 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Radim Vansa > > Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta). > One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using > {code} > Long previous; > do { > previous = cache.get(key); > } while (cache.replace(key, previous, previous + 1); > {code} > which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC. > (so, this JIRA is basically a request to native support for EntryProcessor) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5035) DeltaAware support for conditional operations

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5035?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-5035: ----------------------------------- DistributedExecutorService could be better choice, as long as topology does not change (that's probably OK). However, replication to backups wouldn't spare the bandwidth (unless I implement DeltaAware to produce Deltas and setup IGNORE_RETURN_VALUES to reduce bandwith with RPC response). Even more important concern is that the task wouldn't be executed atomically with the lock locked (so that I don't get write skew and don't have to send whole entry for replace - which in fact does not use deltas), so this would require transactional cache. > DeltaAware support for conditional operations > --------------------------------------------- > > Key: ISPN-5035 > URL: https://issues.jboss.org/browse/ISPN-5035 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Radim Vansa > > Current delta-aware approach is implemented only in PutKeyValueCommand and ApplyDeltaCommand. This implementation does not allow to execute conditional delta-aware commands - or rather it does not allow to return any kind of value (the condition itself can be implemented inside the delta). > One use-case when this would be required is equivalent of AtomicLong.getAndIncrement(). Currently we can implement this using > {code} > Long previous; > do { > previous = cache.get(key); > } while (cache.replace(key, previous, previous + 1); > {code} > which requires at least two RPCs. With more generic interface, such as JCache's EntryProcessor this could be implemented using single RPC. > (so, this JIRA is basically a request to native support for EntryProcessor) -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5046) PartitionHandling: split during commit can leave the cache inconsistent after merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5046?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5046: ------------------------------- Status: Open (was: New) > PartitionHandling: split during commit can leave the cache inconsistent after merge > ----------------------------------------------------------------------------------- > > Key: ISPN-5046 > URL: https://issues.jboss.org/browse/ISPN-5046 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final, 7.1.0.Alpha1 > Reporter: Dan Berindei > Priority: Critical > Fix For: 7.1.0.Beta1 > > > Say we have a cluster ABCD; a transaction T was started on A, with B as the primary owner and C the backup owner. B and C both acknowledge the prepare, and the network splits into AB and CD right before A sends the commit command. Eventually A suspects C and D, but the commit still succeeds on B before C and D are suspected. And SuspectExceptions are ignored for commit commands, so the user won't see any error. > However, C will eventually suspect A and B. When the CD cache topology is installed, it will roll back transaction T. After the merge, both partitions are in degraded mode, so we assume that they both have the latest data and the key is never updated on C. > From C's point of view, this is very similar to ISPN-3421. The fix should also be similar, we could delay the transaction rollback on C until we get a confirmation from B that T was not committed there. Since B is inaccessible, it will eventually get a SuspectException and the CD cache topology, at which point the cache is in degraded mode and it can wait for a merge. On merge, it should check the status of the transaction on B again, and either commit or rollback based on what B did. > We also need to suspend the cleanup of completed transactions while the cache is in degraded mode, otherwise C might not find T on B after the merge. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2014