[JBoss JIRA] (ISPN-5806) Add transaction support for Functional API
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5806?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5806:
----------------------------------
Fix Version/s: (was: 8.2.0.Final)
> Add transaction support for Functional API
> ------------------------------------------
>
> Key: ISPN-5806
> URL: https://issues.jboss.org/browse/ISPN-5806
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
>
> A local cache with batching enabled produces this:
> {code:java}
> java.lang.IllegalArgumentException: Cannot create a transactional
> context without a valid Transaction instance.
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
> at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
> at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
> at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
> (<-- experimental uncommitted code here)
> {code}
> For single operations that carry no transaction context, don't try to start a transaction and create a transactional context.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6322) Infinispan can miss incoming commands with JGroupsChannelLookup
by Dan Berindei (JIRA)
Dan Berindei created ISPN-6322:
----------------------------------
Summary: Infinispan can miss incoming commands with JGroupsChannelLookup
Key: ISPN-6322
URL: https://issues.jboss.org/browse/ISPN-6322
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.2.Final, 8.2.0.CR1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.2.0.Final
Normally, the JGroupsTransport startup sequence goes like this:
# Create the {{Channel}}
# Create the {{CommandAwareRpcDispatcher}} and install it as an {{UpHandler}}
# Connect the channel
This way, every {{RequestCorrelator}} message received by the channel is passed up to {{CommandAwareRpcDispatcher}}, which executes the appropriate command.
When using a {{JGroupsChannelLookup}}, the lookup implementation is allowed to return a {{Channel}} instance that is already connected ({{shouldConnect() == false}}). That means there is now a window where the channel doesn't have an {{UpHandler}}, and messages sent to this node are discarded.
Normally a node only receives commands after it sent a join request to the coordinator. There are however a few exceptions:
# On startup, {[LocalTopologyManagerImpl}} sends the join request to the JGroups coordinator, which may not have the {{UpHandler}} yet. This seems to be responsible for the recent hanging in {{ConcurrentStartTest}}. We have a workaround here, to use a smaller timeout on the {{CacheTopologyControlCommand(JOIN)}} command, and retry it on {{TimeoutException}}.
# When a node becomes coordinator, {{ClusterTopologyManagerImpl}} broadcasts a {{GET_STATUS}} request to all cluster members, and expects a response from each of them. The same workaround with a smaller timeout and retries might work here.
# In replicated mode, write commands are broadcasted to all cluster members. There is some commented out code in {{RpcManagerImpl.invokeRemotelyAsync()}} that might fix it by only waiting for responses from the cache topology members.
We should consider deprecating {{JGroupsChannelLookup.shouldConnect()}} and requiring that the channel is only connected by {{JGroupsTransport}}. Assuming that works with {{ForkChannel}}, of course.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6321) Adding new cache to newly created cache container throws error
by Martin Gencur (JIRA)
Martin Gencur created ISPN-6321:
-----------------------------------
Summary: Adding new cache to newly created cache container throws error
Key: ISPN-6321
URL: https://issues.jboss.org/browse/ISPN-6321
Project: Infinispan
Issue Type: Bug
Components: CLI, Server
Affects Versions: 8.2.0.CR1
Reporter: Martin Gencur
Steps to reproduce:
1) created new container
{code}
/profile=clustered/subsystem=datagrid-infinispan/cache-container=local:add(default-cache=localTestCache,statistics=true)
{code}
2) create new CONFIGURATIONS object
{code}
/profile=clustered/subsystem=datagrid-infinispan/cache-container=local/configurations=CONFIGURATIONS:add()
{code}
3) create new configuration template
{code}
/profile=clustered/subsystem=datagrid-infinispan/cache-container=local/configurations=CONFIGURATIONS/local-cache-configuration=localTemplate:add(start=EAGER)"
{code}
4) create the cache itself
{code}
/profile=clustered/subsystem=datagrid-infinispan/cache-container=local/local-cache=localTestCache:add(configuration=localTemplate,start=EAGER)"
{code}
The resulting error:
{code}
17:37:54,942 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 33) WFLYCTL0013: Operation ("add") failed - address: ([
[Server:server-one] ("subsystem" => "datagrid-infinispan"),
[Server:server-one] ("cache-container" => "local"),
[Server:server-one] ("local-cache" => "localTestCache")
[Server:server-one] ]) - failure description: {"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
[Server:server-one] "Services that were unable to start:" => ["jboss.datagrid-infinispan.local.localTestCache"],
[Server:server-one] "Services that may be the cause:" => [
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.async-operations",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.expiration",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.listener",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.persistence",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.remote-command",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.replication-queue",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.state-transfer",
[Server:server-one] "jboss.datagrid-infinispan.local.config.thread-pool.transport"
[Server:server-one] ]
[Server:server-one] }}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6318) Cleanup AbstractAuthentication tests
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6318?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6318:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.2.0.Final
Resolution: Done
> Cleanup AbstractAuthentication tests
> ------------------------------------
>
> Key: ISPN-6318
> URL: https://issues.jboss.org/browse/ISPN-6318
> Project: Infinispan
> Issue Type: Task
> Components: Security, Test Suite - Core
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Fix For: 8.2.0.Final
>
>
> Test using {{adminCache}} and {{writerCache}} seems to be completely useless as these caches are not secured. Remote these tests from {{AbstractAuthentication}}
> Thanks [~dan.berindei] for spotting this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month