February 2016 - infinispan-issues

[JBoss JIRA] (ISPN-6131) ScriptingManager.removeScript throws ISPN026005 exception when the script exists

by Anna Manukyan (JIRA)

[ https://issues.jboss.org/browse/ISPN-6131?page=com.atlassian.jira.plugin.... ] Anna Manukyan updated ISPN-6131: -------------------------------- Description: ScriptingManager.removeScript() method call with existing script name throws following exception: org.infinispan.commons.CacheException: ISPN026005: No script named 'test.js' at org.infinispan.scripting.impl.ScriptingManagerImpl.removeScript(ScriptingManagerImpl.java:121) at org.infinispan.scripting.ScriptingTest.testRemovingScript(ScriptingTest.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) ... The test code for script removing is: {code:java} public void testRemovingScript() throws Exception { assertNotNull(cacheManager.getCache(ScriptingManager.SCRIPT_CACHE).get("test.js")); scriptingManager.removeScript("test.js"); assertNull(cacheManager.getCache(ScriptingManager.SCRIPT_CACHE).get("test.js")); } {code} was: ScriptingManager.removeScript() method call with existing script name throws following exception: org.infinispan.commons.CacheException: ISPN026005: No script named 'test.js' at org.infinispan.scripting.impl.ScriptingManagerImpl.removeScript(ScriptingManagerImpl.java:121) at org.infinispan.scripting.ScriptingTest.testRemovingScript(ScriptingTest.java:61) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) ... The test code is: {code:java} public void testRemovingScript() throws Exception { assertNotNull(cacheManager.getCache(ScriptingManager.SCRIPT_CACHE).get("test.js")); scriptingManager.removeScript("test.js"); assertNull(cacheManager.getCache(ScriptingManager.SCRIPT_CACHE).get("test.js")); } {code} > ScriptingManager.removeScript throws ISPN026005 exception when the script exists > --------------------------------------------------------------------------------- > > Key: ISPN-6131 > URL: https://issues.jboss.org/browse/ISPN-6131 > Project: Infinispan > Issue Type: Bug > Reporter: Anna Manukyan > Assignee: Tristan Tarrant > > ScriptingManager.removeScript() method call with existing script name throws following exception: > org.infinispan.commons.CacheException: ISPN026005: No script named 'test.js' > at org.infinispan.scripting.impl.ScriptingManagerImpl.removeScript(ScriptingManagerImpl.java:121) > at org.infinispan.scripting.ScriptingTest.testRemovingScript(ScriptingTest.java:61) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > ... > The test code for script removing is: > {code:java} > public void testRemovingScript() throws Exception { > assertNotNull(cacheManager.getCache(ScriptingManager.SCRIPT_CACHE).get("test.js")); > scriptingManager.removeScript("test.js"); > assertNull(cacheManager.getCache(ScriptingManager.SCRIPT_CACHE).get("test.js")); > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6136) OptimisticLockingTxClusterExtendedStatisticLogicTest random failures with SyncConsistentHashFactory

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6136?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6136: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.Final Resolution: Done > OptimisticLockingTxClusterExtendedStatisticLogicTest random failures with SyncConsistentHashFactory > --------------------------------------------------------------------------------------------------- > > Key: ISPN-6136 > URL: https://issues.jboss.org/browse/ISPN-6136 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.2.0.Beta1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.CR1, 8.2.0.Final > > > {{OptimisticLockingTxClusterExtendedStatisticLogicTest}}, like {{PessimisticLockingTxClusterExtendedStatisticLogicTest}}, requires the coordinator to own the test key, and that is no longer guaranteed since {{SyncConsistentHashFactory}} became the default CH factory. > The {{ISPN-4851}} commit included a fix for {{PessimisticLockingTxClusterExtendedStatisticLogicTest}}, and {{OptimisticLockingTxClusterExtendedStatisticLogicTest}} needs a similar fix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6146) XA transactions already committed in prepare as XA_RDONLY fail on commit with "ISPN000112: exception while committing: javax.transaction.xa.XAException"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-6146?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated ISPN-6146: --------------------------------- Status: Pull Request Sent (was: Pull Request Sent) Git Pull Request: https://github.com/infinispan/infinispan/pull/3979, https://github.com/infinispan/infinispan/pull/3993 (was: https://github.com/infinispan/infinispan/pull/3979) > XA transactions already committed in prepare as XA_RDONLY fail on commit with "ISPN000112: exception while committing: javax.transaction.xa.XAException" > -------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-6146 > URL: https://issues.jboss.org/browse/ISPN-6146 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 8.2.0.Beta1, 8.1.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > {noformat} > 15:34:39,087 WARN [org.infinispan.transaction.tm.DummyTransaction] (default task-1) ISPN000112: exception while committing: javax.transaction.xa.XAException > at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:242) > at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:235) > at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:103) > at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:389) > at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:435) > at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:314) > at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:105) > at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73) > at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48) > at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:77) > at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768) > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6128) Expose ProtoBuf Manager through DMR

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6128?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-6128: ------------------------------------------- The commit is e1cc7157b3d4fb2457237c9eb39036ce60fb3212 > Expose ProtoBuf Manager through DMR > ----------------------------------- > > Key: ISPN-6128 > URL: https://issues.jboss.org/browse/ISPN-6128 > Project: Infinispan > Issue Type: Task > Components: Remote Querying, Server > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 8.2.0.CR1, 8.2.0.Final > > > The ProtoBuf Manager should be exposed through the DMR as a child resource under cache-container nodes. The resource should expose a number of operations to list, get, set, remove installed schemas. > Example: > .../cache-container=container/protobuf-schemas=PROTOBUF-SCHEMAS > :list-schemas() > :get-schema(name=myschema) > :remove-schema(name=myschema) > :set-schema(name=myschema, schema-source=...) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6188) DMR Script management ops

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6188?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-6188: -------------------------------------- Status: Resolved (was: Pull Request Sent) Release Notes Text: Integrated with 7d0aa9295ccb0ee289e334d9dcca30304ec21908 Resolution: Done > DMR Script management ops > -------------------------- > > Key: ISPN-6188 > URL: https://issues.jboss.org/browse/ISPN-6188 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.CR1 > > > Add the following script management ops to the DMR: > * script-add(name=name, code=code) > * script-remove(name=name) > * script-cat(name=name) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6185) Allow task execution/listing from DMR

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6185?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-6185: -------------------------------------- Status: Resolved (was: Pull Request Sent) Release Notes Text: Integrated with fcca3c7c1ed6d17b3a9ad3921ac2e78a979f7bb8 Resolution: Done > Allow task execution/listing from DMR > ------------------------------------- > > Key: ISPN-6185 > URL: https://issues.jboss.org/browse/ISPN-6185 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.2.0.CR1 > > > Expose a series of commands on a cache container in the server to be able to: > * list available tasks > * list running tasks > * execute a task -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5868) Infinispan Server CLI container command doesn't work

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5868?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5868: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.CR1 8.1.2.Final Resolution: Done > Infinispan Server CLI container command doesn't work > ---------------------------------------------------- > > Key: ISPN-5868 > URL: https://issues.jboss.org/browse/ISPN-5868 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 8.0.1.Final > Reporter: Karl von Randow > Assignee: Martin Gencur > Fix For: 8.2.0.CR1, 8.1.2.Final > > > The Infinispan Server CLI has a "container" command which doesn't appear to work anymore under 8.0.1. I _suspect_ it's because the Infinispan subsystem was renamed from "infinispan" to "datagrid-infinispan", however I can't find where that change should be made! It appears it should be in the CLI Connection implementation, but I can't for the life of me find the HTTP Connection that I believe is being used in this case. > If someone can point me to the right class I'd be happy to change and test the fix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6192) Short-term memory leak caused by RPCs that complete prior to their timeout

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6192?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6192: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.CR1 8.1.2.Final Resolution: Done > Short-term memory leak caused by RPCs that complete prior to their timeout > -------------------------------------------------------------------------- > > Key: ISPN-6192 > URL: https://issues.jboss.org/browse/ISPN-6192 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Beta1, 8.1.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 8.2.0.CR1, 8.1.2.Final > > > The CommandAwareRpcDispatcher uses the timeout executor to trigger the cancellation of an async rpc after some timeout. However, in the event that the command executes prior to the timeout (i.e. most of the time), the task remains in the timeout executor's queue. Consequently, the reference to the RspListFuture/SingleResponseFuture will remain in the executor's queue unnecessarily for the duration of the timeout. > Using ScheduledThreadPoolExecutor.setRemoveOnCancelPolicy(true) should fix the problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6192) Short-term memory leak caused by RPCs that complete prior to their timeout

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-6192?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-6192: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3991, https://github.com/infinispan/infinispan/pull/3992 > Short-term memory leak caused by RPCs that complete prior to their timeout > -------------------------------------------------------------------------- > > Key: ISPN-6192 > URL: https://issues.jboss.org/browse/ISPN-6192 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Beta1, 8.1.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > The CommandAwareRpcDispatcher uses the timeout executor to trigger the cancellation of an async rpc after some timeout. However, in the event that the command executes prior to the timeout (i.e. most of the time), the task remains in the timeout executor's queue. Consequently, the reference to the RspListFuture/SingleResponseFuture will remain in the executor's queue unnecessarily for the duration of the timeout. > Using ScheduledThreadPoolExecutor.setRemoveOnCancelPolicy(true) should fix the problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6192) Short-term memory leak caused by RPCs that complete prior to their timeout

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-6192?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-6192: ------------------------------- Status: Open (was: New) > Short-term memory leak caused by RPCs that complete prior to their timeout > -------------------------------------------------------------------------- > > Key: ISPN-6192 > URL: https://issues.jboss.org/browse/ISPN-6192 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.Beta1, 8.1.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > The CommandAwareRpcDispatcher uses the timeout executor to trigger the cancellation of an async rpc after some timeout. However, in the event that the command executes prior to the timeout (i.e. most of the time), the task remains in the timeout executor's queue. Consequently, the reference to the RspListFuture/SingleResponseFuture will remain in the executor's queue unnecessarily for the duration of the timeout. > Using ScheduledThreadPoolExecutor.setRemoveOnCancelPolicy(true) should fix the problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 2016