February 2019 - infinispan-issues

[JBoss JIRA] (ISPN-8124) ServerNG: Initial implementation

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8124?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8124: ---------------------------------- Fix Version/s: 10.0.0.Beta1 (was: 10.0.0.Final) > ServerNG: Initial implementation > -------------------------------- > > Key: ISPN-8124 > URL: https://issues.jboss.org/browse/ISPN-8124 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta1 > > > First implementation of the server. > This task focuses on organization of the server, directory layout, configuration, boot process and initial testing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[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"> >  > <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, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-9884) SoftIndexFileStore.destroy leaks threads

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9884?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9884: ---------------------------------- Fix Version/s: 10.0.0.Beta2 (was: 10.0.0.Beta1) > SoftIndexFileStore.destroy leaks threads > ---------------------------------------- > > Key: ISPN-9884 > URL: https://issues.jboss.org/browse/ISPN-9884 > 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 > > > {{SoftIndexFileStore.destroy()}} doesn't call {{Index.stopOperations()}}, so the index threads keep on running. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (ISPN-9657) Multimap jar is not OSGi compliant

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9657?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9657: ---------------------------------- Fix Version/s: 10.0.0.Beta2 (was: 10.0.0.Beta1) > Multimap jar is not OSGi compliant > ---------------------------------- > > Key: ISPN-9657 > URL: https://issues.jboss.org/browse/ISPN-9657 > Project: Infinispan > Issue Type: Bug > Components: Multimap > Affects Versions: 9.4.0.Final > Reporter: Alain Picard > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta2, 10.0.0.Final, 9.4.8.Final > > > Due to issues related to using the embedded jar (see [here|https://developer.jboss.org/message/986042#986042], when switching to individual jars, the multimap jar (infinispan-multimap-9.4.0.Final.jar) doesn't provide a valid OSGi manifest. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2019