January 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9880) Docs: Hot Rod Transaction Support Feedback

by Don Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-9880?page=com.atlassian.jira.plugin.... ] Don Naro closed ISPN-9880. -------------------------- > Docs: Hot Rod Transaction Support Feedback > ------------------------------------------ > > Key: ISPN-9880 > URL: https://issues.jboss.org/browse/ISPN-9880 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 10.0.0.Beta1, 9.4.6.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.7.Final > > > https://access.qa.redhat.com/documentation/en-us/red_hat_data_grid/7.3/ht... > Feedback for on Hot Rod Transaction docs: > Server Guide > - 6.2.6 Transactions > Remove: While it is possible to configure server caches to be transactional, none of the available protocols offer transaction capabilities. > User Guide > - 20.7.21.2.2 Transaction Modes > "The transaction mode names are the same for server configuration and for client settings. > To prevent from confusion it should be clarified here that this is the client setting > and the server will not work correctly if the client use Tx but the server has no Tx setting. > This should fail at runtime if the client request a Tx for a non-tx-cache (but I did not tested this yet)" > - 20.7.21 > "The introducing paragraph and the tip mention that the client side Tx is quasi optimistic. > But there is no highlighted node that the consistence is possibly affected by that. > There should be a warning and a link to the detailed description 20.7.21.4 to makes this as clear as possible." > Additionally: > "to make it simple for the user if you don't highlight to implement a custom TxManager, this is only needed to integrate other implementations. > If not needed, the GenericTxM is the best choice as it will use our TxM inside EAP or the RemoteTxM if there is nothing found. > So this will be 99% of the use cases (or more)" -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4075: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > State transfer should preserve the creation timestamp of entries > ---------------------------------------------------------------- > > Key: ISPN-4075 > URL: https://issues.jboss.org/browse/ISPN-4075 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1, 10.0.0.Final, 9.4.7.Final > > > State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended. > The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4075: ---------------------------------- Fix Version/s: 10.0.0.Beta1 9.4.7.Final (was: 10.0.0.Alpha3) (was: 9.4.5.Final) > State transfer should preserve the creation timestamp of entries > ---------------------------------------------------------------- > > Key: ISPN-4075 > URL: https://issues.jboss.org/browse/ISPN-4075 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1, 10.0.0.Final, 9.4.7.Final > > > State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended. > The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9888) Docs: Default JGroups for Infinispan

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9888?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9888: ---------------------------------- Affects Version/s: (was: 10.0.0.Beta1) > Docs: Default JGroups for Infinispan > ------------------------------------ > > Key: ISPN-9888 > URL: https://issues.jboss.org/browse/ISPN-9888 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 9.4.5.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 9.4.7.Final > > > Default properties in jgroups-defaults.xml are not the same as JGroups defaults. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9888) Docs: Default JGroups for Infinispan

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9888?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9888: ---------------------------------- Fix Version/s: (was: 10.0.0.Beta1) > Docs: Default JGroups for Infinispan > ------------------------------------ > > Key: ISPN-9888 > URL: https://issues.jboss.org/browse/ISPN-9888 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 9.4.5.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 9.4.7.Final > > > Default properties in jgroups-defaults.xml are not the same as JGroups defaults. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9888) Docs: Default JGroups for Infinispan

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9888?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9888: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta1 9.4.7.Final Resolution: Done > Docs: Default JGroups for Infinispan > ------------------------------------ > > Key: ISPN-9888 > URL: https://issues.jboss.org/browse/ISPN-9888 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Affects Versions: 10.0.0.Beta1, 9.4.5.Final > Reporter: Don Naro > Assignee: Don Naro > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.7.Final > > > Default properties in jgroups-defaults.xml are not the same as JGroups defaults. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9699) Cluster member owning no data

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-9699: ------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/6440, https://github.com/infinispan/infinispan/pull/6633 (was: https://github.com/infinispan/infinispan/pull/6440) > Cluster member owning no data > ----------------------------- > > Key: ISPN-9699 > URL: https://issues.jboss.org/browse/ISPN-9699 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 9.4.1.Final > Reporter: Thomas Segismont > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.7.Final > > > Currently, you can set {{capacity-factor}} to zero on a cache if you don't want a node to own any segment. > If you want a node to own no data at all, you could set this property on all declared caches. But this wouldn't work for internal caches anyway (locks, counters). > It would be nice to have a global switch. > This would be useful when your app needs to be a cluster member for discovery/membership but is deployed mostly for processing. Indeed, when such nodes are added/removed from the cluster: > * there would be no data loss > * the cluster would be back in healthy state faster as no data would be moved around. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9910) Introduce an AdvancedCache.as(Subject) method for explicit authorization

by Diego Lovison (Jira)

Diego Lovison created ISPN-9910: ----------------------------------- Summary: Introduce an AdvancedCache.as(Subject) method for explicit authorization Key: ISPN-9910 URL: https://issues.jboss.org/browse/ISPN-9910 Project: Infinispan Issue Type: Feature Request Components: Core, Security Reporter: Diego Lovison Assignee: Tristan Tarrant Fix For: 9.1.0.Alpha1 Currently the subject is extracted either from the AccessControlContext or from the lightweight security implementation (which uses a ThreadLocal). Both of these approaches have fairly high costs, so we should, if possible, use an explicit Subject. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9909) Immutable Configuration Storage

by Diego Lovison (Jira)

Diego Lovison created ISPN-9909: ----------------------------------- Summary: Immutable Configuration Storage Key: ISPN-9909 URL: https://issues.jboss.org/browse/ISPN-9909 Project: Infinispan Issue Type: Feature Request Components: Configuration Affects Versions: 9.2.0.CR2 Reporter: Diego Lovison Assignee: Tristan Tarrant Fix For: 9.2.0.Final We need an immutable configuration storage which prevents the creation/removal of caches through the admin api. This is for scenarios where an immutable configuration is desired, e.g. cloud caching service. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9847) Extend configuration to allow inline JGroups configuration and inheritance

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9847?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9847: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Final Resolution: Done > Extend configuration to allow inline JGroups configuration and inheritance > -------------------------------------------------------------------------- > > Key: ISPN-9847 > URL: https://issues.jboss.org/browse/ISPN-9847 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 10.0.0.Alpha2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta1, 10.0.0.Final > > > Allowing inline JGroups configurations to increase usability. > Also support the following extra features: > * stack inheritance with protocol replacement/override > * easier xsite configuration > {code:xml} > <jgroups transport="org.infinispan.remoting.transport.jgroups.JGroupsTransport"> >  > <stack-file name="udp" path="stacks/udp.xml"/> > <stack-file name="tcp" path="stacks/tcp.xml"/> >  > <stack name="mping"> > <TCP bind_port="7800" port_range="30" recv_buf_size="20000000" send_buf_size="640000" > sock_conn_timeout="300" bundler_type="no-bundler" > thread_pool.min_threads="0" thread_pool.max_threads="25" thread_pool.keep_alive_time="5000"/> > <MPING bind_addr="127.0.0.1" break_on_coord_rsp="true" > mcast_addr="${jgroups.mping.mcast_addr:228.2.4.6}" > mcast_port="${jgroups.mping.mcast_port:43366}" > ip_ttl="${jgroups.udp.ip_ttl:2}"/> > <MERGE3/> > <FD_SOCK/> > <FD_ALL timeout="3000" > interval="1000" > timeout_check_interval="1000" > /> > <VERIFY_SUSPECT timeout="1000"/> > <pbcast.NAKACK2 > use_mcast_xmit="false" > xmit_interval="100" > xmit_table_num_rows="50" > xmit_table_msgs_per_row="1024" > xmit_table_max_compaction_time="30000"/> > <UNICAST3 > xmit_interval="100" > xmit_table_num_rows="50" > xmit_table_msgs_per_row="1024" > xmit_table_max_compaction_time="30000" > /> > <RSVP /> > <pbcast.STABLE stability_delay="200" > desired_avg_gossip="2000" > max_bytes="1M" > /> > <pbcast.GMS print_local_addr="false" > join_timeout="${jgroups.join_timeout:2000}"/> > <MFC max_credits="2M" min_threshold="0.40"/> > <FRAG3/> > </stack> >  > <stack name="mytcp" extends="tcp"> > <MERGE3 max_interval="20000"/> > </stack> >  > <stack name="tcpgossip" extends="tcp"> > <TCPGOSSIP initial_hosts="${jgroups.tunnel.gossip_router_hosts:localhost[12001]}" stack.combine="replace:TCP_NIO2"/> > </stack> >  > <stack name="xsite" extends="udp"> > <relay site="LON"> > <remote-site name="NYC" stack="tcpgossip"/> > </relay> > </stack> > </jgroups> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 January 2019