[JBoss JIRA] (ISPN-9847) Extend configuration to allow inline JGroups configuration and inheritance
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9847?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9847:
----------------------------------
Issue Type: Enhancement (was: Bug)
> Extend configuration to allow inline JGroups configuration and inheritance
> --------------------------------------------------------------------------
>
> Key: ISPN-9847
> URL: https://issues.jboss.org/browse/ISPN-9847
> Project: Infinispan
> Issue Type: Enhancement
> 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, 1 month
[JBoss JIRA] (ISPN-9863) Testsuite leaks threads
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9863?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9863:
----------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 10.0.0.Beta1)
> Testsuite leaks threads
> -----------------------
>
> Key: ISPN-9863
> URL: https://issues.jboss.org/browse/ISPN-9863
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta2
>
>
> Some hotrod-client tests do not stop their {{RemoteCacheManager}} instances. This was fine before ISPN-8619, but the Netty-based client starts event loop threads and we need to stop them.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9699) Cluster member owning no data
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9699:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.7.Final
(was: 9.4.8.Final)
Resolution: Done
> 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, 1 month
[JBoss JIRA] (ISPN-9714) Update CacheNotifier to return CompletionStage
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9714?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9714:
----------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 10.0.0.Beta1)
> Update CacheNotifier to return CompletionStage
> ----------------------------------------------
>
> Key: ISPN-9714
> URL: https://issues.jboss.org/browse/ISPN-9714
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core, Listeners
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> We need to update CacheNotifier to return CompletionStage for all its appropriate methods. We also need to update all the internals to use these appropriately.
> Not all notification usages may provide support non blocking, but our listener internals should support non blocking listeners for all.
> The simplest way internally is to treat all current listeners as "alien" and invoke them in the notification thread pool. If it is sync we would wait for this task to complete. We would also now allow a listener to return a CompletionStage. If this is returned we will use this operate in a non blocking way.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9882) JdbcStringBasedStore leaks threads
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9882?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9882:
----------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 10.0.0.Beta1)
> JdbcStringBasedStore leaks threads
> ----------------------------------
>
> Key: ISPN-9882
> URL: https://issues.jboss.org/browse/ISPN-9882
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> When stopping, {{JdbcStringBasedStore}} only stops the connection factory if it implements {{ManagedConnectionFactory}}. {{PooledConnectionFactory}} doesn't implement it, so Agroal connection pools are not closed and leak threads.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9898) JGroupsTransport leaks channel after initial cluster size timeout
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9898?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9898:
----------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 10.0.0.Beta1)
> JGroupsTransport leaks channel after initial cluster size timeout
> -----------------------------------------------------------------
>
> Key: ISPN-9898
> URL: https://issues.jboss.org/browse/ISPN-9898
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> {{JGroupsTransport}} fails during startup if a minimum cluster size is configured and there are not enough nodes. Because the component is in failed, stopping the cache manager does not invoke the stop method and the channel is leaked.
> We could catch the exception in {{JGroupsTransport}} and close the channel there, but it would be safer if {{BasicComponentRegistryImpl}} invoked the stop methods for failed components as well.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9624) Deprecate StreamingMarshaller interface
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9624?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9624:
----------------------------------
Fix Version/s: 10.0.0.Beta2
(was: 10.0.0.Beta1)
> Deprecate StreamingMarshaller interface
> ---------------------------------------
>
> Key: ISPN-9624
> URL: https://issues.jboss.org/browse/ISPN-9624
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core
> Affects Versions: 9.4.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta2
>
>
> The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations.
> {code:java}
> @ThreadSafe
> public interface StreamAwareMarshaller extends Marshaller {
> /**
> * Marshall an object to the {@link OutputStream}
> *
> * @param o the object to write to the {@link OutputStream}
> * @param out the {@link OutputStream} to write the object to
> * @throws IOException if the object cannot be marshalled to the {@link OutputStream} due to some I/O error
> */
> void writeObject(Object o, OutputStream out) throws IOException;
> /**
> * Unmarshall an object from the {@link InputStream}
> *
> * @param in the {@link InputStream} to unmarshall an object from
> * @return the unmarshalled object instance
> * @throws IOException if unmarshalling cannot complete due to some I/O error
> * @throws ClassNotFoundException if the class of the object trying to unmarshall is not found
> */
> Object readObject(InputStream in) throws ClassNotFoundException, IOException;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month