[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
[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
[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
[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
[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
[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">
> <!-- Load external JGroups stacks -->
> <stack-file name="udp" path="stacks/udp.xml"/>
> <stack-file name="tcp" path="stacks/tcp.xml"/>
> <!-- Inline definition -->
> <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>
> <!-- Use the "tcp" stack but override some protocol attributes -->
> <stack name="mytcp" extends="tcp">
> <MERGE3 max_interval="20000"/>
> </stack>
> <!-- Use the "tcp" stack but replace the discovery -->
> <stack name="tcpgossip" extends="tcp">
> <TCPGOSSIP initial_hosts="${jgroups.tunnel.gossip_router_hosts:localhost[12001]}" stack.combine="replace:TCP_NIO2"/>
> </stack>
> <!-- Add a relay configuration using a previously declared stack to talk to the remote site -->
> <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