[JBoss JIRA] (ISPN-3224) RemoteCacheManager of HotRod client is not able connect to server because of wrong parsing IPv6 address for pure IPv6 machines and gets wrong address on dual stack machines
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3224?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3224:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> RemoteCacheManager of HotRod client is not able connect to server because of wrong parsing IPv6 address for pure IPv6 machines and gets wrong address on dual stack machines
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3224
> URL: https://issues.jboss.org/browse/ISPN-3224
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.5.Final, 5.3.0.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 6.0.0.Final
>
>
> ########################Run hotrod client with pure IPv6#############################################
> Hotrod client fails when want connect to server, below is exception from pure IPv6 machines it doesn't really undedstand IPv6 address it should connect."Could not connect to server: /0.0.10.60:52" Here should
> be IPv6 address but it looks like some wrong IPv4 address it want to connect to and I use complicated address 2620:52:0:105f:0:0:ffff:32%2:11222 as host variable and it is not specified in /etc/hosts
> {code}
> public RemoteCacheManager(String host, int port, boolean start, ClassLoader classLoader) {
> config = new ConfigurationProperties(host + ":" + port); <<< host=2620:52:0:105f:0:0:ffff:32%2 and port=11222
> this.classLoader = classLoader;
> if (start) start();
> }
> {code}
>
> then in start method
> {code}
> @Override
> public void start() {
> // Workaround for JDK6 NPE: http://bugs.sun.com/view_bug.do?bug_id=6427854
> SysPropertyActions.setProperty("sun.nio.ch.bugLevel", "\"\"");
> forceReturnValueDefault = config.getForceReturnValues();
> codec = CodecFactory.getCodec(config.getProtocolVersion());
> String factory = config.getTransportFactory();
> transportFactory = (TransportFactory) getInstance(factory, classLoader);
> Collection<SocketAddress> servers = config.getServerList(); <<< we get list of servers but getServerList() method should be improved see below!
>
> transportFactory.start(codec, config, servers, topologyId, classLoader); <<< and pass to transportFactory
> if (marshaller == null) {
> String marshallerName = config.getMarshaller();
> setMarshaller((Marshaller) getInstance(marshallerName, classLoader));
> }
> if (asyncExecutorService == null) {
> String asyncExecutorClass = config.getAsyncExecutorFactory();
> ExecutorFactory executorFactory = (ExecutorFactory) getInstance(asyncExecutorClass, classLoader);
> asyncExecutorService = executorFactory.getExecutor(config.getProperties());
> }
> synchronized (cacheName2RemoteCache) {
> for (RemoteCacheHolder rcc : cacheName2RemoteCache.values()) {
> startRemoteCache(rcc);
> }
> }
> // Print version to help figure client version run
> log.version(org.infinispan.Version.printVersion());
> started = true;
> }
> {code}
>
> and "servers" variable contain the same IP address 2620:52:0:105f:0:0:ffff:32%2:11222
> {code}
> public Collection<SocketAddress> getServerList() {
> Set<SocketAddress> addresses = new HashSet<SocketAddress>();
> String servers = props.getProperty(SERVER_LIST, "127.0.0.1:" + DEFAULT_HOTROD_PORT); <<< got 2620:52:0:105f:0:0:ffff:32%2:11222
> for (String server : servers.split(";")) {
> String[] components = server.trim().split(":"); <<< just only here the splitting it wrong, we devide address into 9 chunks
> String host = components[0]; <<< host name shoud be 1 chunk 2620
> int port = DEFAULT_HOTROD_PORT;
> if (components.length > 1) port = Integer.parseInt(components[1]); <<< and port 52
> addresses.add(new InetSocketAddress(host, port)); <<< and again we pass wrong parameteres to this constructor with IntetSocketAddress(2620, 52)
> }
> if (addresses.isEmpty()) throw new IllegalStateException("No Hot Rod servers specified!");
> return addresses; << here we just get some strange IPv4 address as 0.0.10.60:52
> }
> {code}
> and exception is the following
> {code}
> Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: /0.0.10.60:52
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:88)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:57)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:38)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:271)
> {code}
> ########################Other issue is when hotrod client connects in dual stack mode#################
> /etc/hosts file is---------------------------------------------------------
> 127.0.0.1 myhost localhost.localdomain localhost
> ::1 myhost localhost6.localdomain6 localhost6
> ---------------------------------------------------------------------------
> Then is the same problem in ConfigurationProperties.java getServerList() method we add address to addresses <<<addresses.add(new InetSocketAddress(host, port));>>>
> so InetSocketAddress constructor is called
> {code}
> public InetSocketAddress(String hostname, int port) {
> checkHost(hostname);
> InetAddress addr = null;
> String host = null;
> try {
> addr = InetAddress.getByName(hostname); <<< we should get InetAddress with hostname
> } catch(UnknownHostException e) {
> host = hostname;
> }
> holder = new InetSocketAddressHolder(host, addr, checkPort(
> }
> {code}
> but we have 2! different inet addresses with the same hostname one is 127.0.0.1 and other ::1 and if i run it on IPv6 there should be ::1 and not 127.0.0.1!
> And
> public static InetAddress getByName(String host)
> throws UnknownHostException {
> return InetAddress.getAllByName(host)[0]; <<< but here we get only first address in array and got always 127.0.0.1
> }
> and then other exception is thrown
> {code}
> Caused by: org.infinispan.client.hotrod.exceptions.TransportException:: Could not connect to server: vchepQA/127.0.0.1:11222
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.<init>(TcpTransport.java:88)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:57)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:38)
> at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.borrowTransportFromPool(TcpTransportFactory.java:271)
> ... 97 more
> {code}
> and i forget to add trace log just download it here http://dropmefiles.com/en/H5wvu
> ##################################################INFINISPAN 5.3.0.FINAL#####################################################################
> org.infinispan.client.hotrod.configuration.ConfigurationBuilder has this method
> {code}
> @Override
> public ConfigurationBuilder addServers(String servers) {
> for (String server : servers.split(";")) {
> String[] components = server.trim().split(":");
> String host = components[0];
> int port = ConfigurationProperties.DEFAULT_HOTROD_PORT;
> if (components.length > 1)
> port = Integer.parseInt(components[1]);
> this.addServer().host(host).port(port);
> }
> return this;
> }
> {code}
> And what if I put in <servers> argument something like addServers("[fe80::3e97:eff:fe19:3045]:11222;[fe80::3e97:eff:fe19:3046]:11322")? I think that It is not parsing correctly and we can use
> <servers> argument something like addServers("localhost6:11222; localhost6.localdomain6:11322") or other ipv6 hostnames.
> Because I want to use ip addresses and not hostnames and not to change /etc/hosts file only for mapping ipv6 address to some dummy hostname
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (ISPN-3223) HotRod Client recieves stale toplogy view on instance leave
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3223?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3223:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> HotRod Client recieves stale toplogy view on instance leave
> -----------------------------------------------------------
>
> Key: ISPN-3223
> URL: https://issues.jboss.org/browse/ISPN-3223
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 5.2.4.Final, 5.3.0.CR1
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Fix For: 6.0.0.Final
>
>
> When killed a HotRod server node, HotRod Clinet sometimes recieves a stale toplogy view which includes the dead node and uses it as a latest view. In this case the client keeps trying to connect that node and keeps failing.
> Looks like the AbstractEncoder1x.generateTopologyResponse() takes care of node join but doesn't handle node leave:
> {noformat}
> if (!serverEndpointsMap.keySet.containsAll(cacheMembers)) {
> {noformat}
> For example, serverEndpointsMap.keySet is [A, B, C] and the actual cacheMembers is [A, B].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (ISPN-3287) Possible inconsistency with concurrent transactions during state transfer
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3287?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3287:
--------------------------------
Fix Version/s: (was: 6.0.0.CR1)
> Possible inconsistency with concurrent transactions during state transfer
> -------------------------------------------------------------------------
>
> Key: ISPN-3287
> URL: https://issues.jboss.org/browse/ISPN-3287
> Project: Infinispan
> Issue Type: Bug
> Components: Locking and Concurrency, State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
>
> It looks like there is a data race between the state transfer thread and a concurrent transaction in EntryWrappingInterceptor.commitEntryIfNeeded:
> tx: commitContextEntry()
> ST: stateConsumer.isKeyUpdated(k)? false
> tx: stateConsumer.addUpdatedKey(k)
> ST: commitContextEntry()
> We probably need some synchronization here, maybe using EquivalentConcurrentHashMapV8.computeIfAbsent().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (ISPN-3270) Hotrod clients removeWithVersion doesn't work with replicated cache
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3270?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3270:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> Hotrod clients removeWithVersion doesn't work with replicated cache
> -------------------------------------------------------------------
>
> Key: ISPN-3270
> URL: https://issues.jboss.org/browse/ISPN-3270
> Project: Infinispan
> Issue Type: Bug
> Components: Remote protocols
> Affects Versions: 6.0.0.Beta1
> Reporter: Jakub Markos
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: server-trace-logs.zip
>
>
> I have a cluster of 2 latest infinispan servers (6.0.0-SNAPSHOT) with the following container configuration:
> {code:xml}<cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <replicated-cache name="default" start="EAGER" mode="SYNC" batching="false" remote-timeout="60000">
> <transaction mode="NONE"/>
> <state-transfer enabled="true" timeout="60000"/>
> </replicated-cache>
> </cache-container>
> {code}
> Running this code:
> {code} remoteCache = remoteCacheManager.getCache();
> remoteCache.clear();
> assertFalse(remoteCache.removeWithVersion("aKey", 12321212l));
> remoteCache.put("aKey", "aValue");
> VersionedValue valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> System.out.println(remoteCache.removeWithVersion("aKey",valueBinary.getVersion()));
> valueBinary = remoteCache.getVersioned("aKey");
> System.out.println("value = " + valueBinary.getValue());
> System.out.println("version = " + valueBinary.getVersion());
> {code}
> results most of the time in (and the other times the removeWithVersion returns false)
> {quote}
> value = aValue
> version = 281483566645249
> true
> value = aValue
> version = 281483566645249
> {quote}
> The command works with distributed/local cache.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (ISPN-3306) RehashWithSharedCacheStoreTest.testRehashes fails randomly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3306?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3306:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> RehashWithSharedCacheStoreTest.testRehashes fails randomly
> ----------------------------------------------------------
>
> Key: ISPN-3306
> URL: https://issues.jboss.org/browse/ISPN-3306
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Pedro Ruivo
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: RehashWithSharedCacheStoreTest.testRehashes.tar.gz
>
>
> {code:java}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node RehashWithSharedCacheStoreTest-NodeB-2392, current topology is CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashWithSharedCacheStoreTest-NodeB-2392, RehashWithSharedCacheStoreTest-NodeC-18606]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashWithSharedCacheStoreTest-NodeB-2392, RehashWithSharedCacheStoreTest-NodeC-18606]}}
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:181)
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:191)
> at org.infinispan.distribution.rehash.RehashWithSharedCacheStoreTest.testRehashes(RehashWithSharedCacheStoreTest.java:76)
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (ISPN-3309) EntryWrappingInterceptor should not wrap entries on the originator in non-tx mode
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3309?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3309:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> EntryWrappingInterceptor should not wrap entries on the originator in non-tx mode
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3309
> URL: https://issues.jboss.org/browse/ISPN-3309
> Project: Infinispan
> Issue Type: Task
> Components: Locking and Concurrency
> Affects Versions: 5.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 6.0.0.Final
>
>
> EntryWrappingInterceptor assumes that lock delegation is only enabled in dist caches, so in a repl cache it will wrap the entry twice. This may mean that the entry is also written to the data container twice.
> I have tried changing this assumption in the context of ISPN-3289, but it caused some failures in ClusteredCacheWithRamDirIndexManagerTest and ClusteredCacheWithInfinispanDirectoryTest. The query interceptor may be assuming that the entries are committed to the data container when {{ctx.isOriginLocal() == true}}, so it warrants a more thorough investigation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (ISPN-3304) ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit fails randomly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3304?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3304:
--------------------------------
Fix Version/s: 6.0.0.Final
(was: 6.0.0.CR1)
> ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit fails randomly
> -------------------------------------------------------------------------------
>
> Key: ISPN-3304
> URL: https://issues.jboss.org/browse/ISPN-3304
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final
> Reporter: Pedro Ruivo
> Assignee: Mircea Markus
> Fix For: 6.0.0.Final
>
> Attachments: ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit.tar.gz
>
>
> {code:java}
> java.lang.RuntimeException: Timed out before caches had complete views. Expected 3 members in each view. Views are as follows: [[ClusterTopologyManagerTest-NodeL-25341], [ClusterTopologyManagerTest-NodeN-52944, ClusterTopologyManagerTest-NodeM-9914], [ClusterTopologyManagerTest-NodeN-52944, ClusterTopologyManagerTest-NodeM-9914]]
> at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:232)
> at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:222)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:214)
> at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:255)
> at org.infinispan.statetransfer.ClusterTopologyManagerTest.testClusterRecoveryAfterThreeWaySplit(ClusterTopologyManagerTest.java:156)
> ...
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months