November 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3706) Test AS modules against WildFly 8

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3706?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3706: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Test AS modules against WildFly 8 > --------------------------------- > > Key: ISPN-3706 > URL: https://issues.jboss.org/browse/ISPN-3706 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 6.0.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 6.0.0.Final > > -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3706) Test AS modules against WildFly 8

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3706?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3706: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2218 > Test AS modules against WildFly 8 > --------------------------------- > > Key: ISPN-3706 > URL: https://issues.jboss.org/browse/ISPN-3706 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 6.0.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 6.0.0.Final > > -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3706) Test AS modules against WildFly 8

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3706: ------------------------------------- Summary: Test AS modules against WildFly 8 Key: ISPN-3706 URL: https://issues.jboss.org/browse/ISPN-3706 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 6.0.0.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 6.0.0.Final -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3705) JGroupsChannelProvider changes break Infinispan Server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3705?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3705: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/182 > JGroupsChannelProvider changes break Infinispan Server > ------------------------------------------------------ > > Key: ISPN-3705 > URL: https://issues.jboss.org/browse/ISPN-3705 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3705) JGroupsChannelProvider changes break Infinispan Server

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3705: ------------------------------------- Summary: JGroupsChannelProvider changes break Infinispan Server Key: ISPN-3705 URL: https://issues.jboss.org/browse/ISPN-3705 Project: Infinispan Issue Type: Bug Components: Server Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Blocker -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3697) Improved lifecycle control of JGroupsChannelLookup

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3697?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3697: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. In she future we should try to fix any problems with handing an already-connected Channel to Infinispan. > Improved lifecycle control of JGroupsChannelLookup > -------------------------------------------------- > > Key: ISPN-3697 > URL: https://issues.jboss.org/browse/ISPN-3697 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 6.0.0.CR1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 6.0.0.Final > > > Currently, a JGroupsChannelLookup can indicate whether the JGroupsTransport should connect the provided channel and disconnect/close the provided channel. > In the case of Wildfly, we'd like to distinguish between disconnect and close. We have a service that provided the channel, but we allow the JGroupsTransport to manage the lifecycle. This leads to conditions where infinispan's cache manager can restart, but the jgroups channel service does not, e.g. > https://issues.jboss.org/browse/WFLY-2458 > To fix this, I need to introduce hacks into the channel returned by the channel service, such that Channel.close() is a no-op, and introduce a separate method invisible to Infinispan to perform the actual close(). > So what I propose is the following: > boolean shouldConnect(); // Notice that I renamed this, because there is no such distinction between "start" and "connect". > boolean shouldDisconnect(); > boolean shouldClose(); -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3670) Any commands received before the initial topology is installed should block

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3670?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-3670. --------------------------------- Resolution: Done > Any commands received before the initial topology is installed should block > --------------------------------------------------------------------------- > > Key: ISPN-3670 > URL: https://issues.jboss.org/browse/ISPN-3670 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.CR2 > > > Because the initial cache topology is installed in a single phase, it's possible to receive a StateRequestCommand from another node before receiving the JOIN response from the coordinator and installing the initial cache topology. As such, commands received before we have a cache topology should block instead of being ignored. > This bug is especially visible in the Map/Reduce tests (e.g. ReplicatedTwoNodesMapReduceTest) because the M/R task sends the CreateCacheCommand to the other nodes before it's executed on the originator. Since the originator happens to be the coordinator, it's possible for the coordinator to start the rebalance before the first member installed the initial topology. -- 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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3704: ----------------------------------- Increasing priority as the remote get timeout is pretty long and if the ST transaction gets aborted (due to timeout), we lose that entry. > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3704: ------------------------------ Priority: Critical (was: Major) > StateTransfer's PutKeyValueCommand may trigger remote get > --------------------------------------------------------- > > Key: ISPN-3704 > URL: https://issues.jboss.org/browse/ISPN-3704 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > In TX mode with write skew check on, ST executing puts may trigger a remote get. > The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from > {code} > if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {code} > to > {code} > if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))) > remoteGetBeforeWrite(ctx, command, recipientGenerator); > {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

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3454) Hot Rod client doesn't retry operation on RemoteException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3454?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3454: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Hot Rod client doesn't retry operation on RemoteException > --------------------------------------------------------- > > Key: ISPN-3454 > URL: https://issues.jboss.org/browse/ISPN-3454 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final, 6.0.0.Alpha3 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Critical > Labels: 620 > Fix For: 6.0.0.CR2, 6.0.0.Final > > > This is a client-side problem. > In a resilience test with 4 nodes where 1 is killed, I'm getting a lot of these: > {code} > 08:30:55,198 ERROR [org.jboss.smartfrog.jdg.loaddriver.DriverThread] (DriverThread-369) Error doing: PUT key399869 to node node04, took 493 ms > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[821188] returned server error (status=0x85): org.infinispan.remoting.RemoteException: ISPN000217: Received exception from node01/default, see cause for remote stack trace > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:209) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79) > at org.jboss.qa.jdg.adapter.Infinispan60Adapter$HotRodRemoteCacheAdapter.put(Infinispan60Adapter.java:269) > at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.makeRequest(DriverThreadImpl.java:265) > at org.jboss.smartfrog.jdg.loaddriver.DriverThreadImpl.run(DriverThreadImpl.java:378) > {code} > Isn't this a recoverable problem that shouldn't be left to user to handle ? > source: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/RESILIENCE... -- 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

12 years, 5 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 November 2013