[JBoss JIRA] (ISPN-1876) clustered query is not executed on the right cache
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-1876?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-1876:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.3.0.Beta1
5.3.0.Final
Resolution: Done
> clustered query is not executed on the right cache
> --------------------------------------------------
>
> Key: ISPN-1876
> URL: https://issues.jboss.org/browse/ISPN-1876
> Project: Infinispan
> Issue Type: Bug
> Components: Querying, RPC
> Affects Versions: 5.1.1.FINAL
> Reporter: Mathieu Lachance
> Assignee: Israel Lacerra
> Fix For: 5.3.0.Beta1, 5.3.0.Final
>
>
> when using clustered query, command is not executed on the right cache.
> when debuging, in CommandAwareRpcDispatcher::executeCommand()
> cmd = ClusteredQuery{cache="the-good-cache-name"}
> cmd.cache = "the-bad-cache-name"
> cmd.cacheName = "the-good-cache-name"
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-2982) CLONE - State transfer does not end because some segments are erroneously reported as unreceived
by Ittay Dror (JIRA)
[ https://issues.jboss.org/browse/ISPN-2982?page=com.atlassian.jira.plugin.... ]
Ittay Dror commented on ISPN-2982:
----------------------------------
It still happens... I also upgraded to 5.2.5, still same error.
Tried to switch to udp based configuration, seems like the exception doesn't happen.
> CLONE - State transfer does not end because some segments are erroneously reported as unreceived
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-2982
> URL: https://issues.jboss.org/browse/ISPN-2982
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.1.Final
> Reporter: Ittay Dror
> Assignee: Adrian Nistor
> Priority: Critical
> Attachments: jgroups.xml
>
>
> Hard to reproduce. I lost the last log where this was visible but still have a stack trace:
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:879)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:650)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:639)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:542)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:197)
> at org.infinispan.CacheImpl.start(CacheImpl.java:517)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:689)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:652)
> at org.infinispan.manager.DefaultCacheManager.access$100(DefaultCacheManager.java:126)
> at org.infinispan.manager.DefaultCacheManager$1.run(DefaultCacheManager.java:574)
> Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache LuceneIndexesMetadata on PersistentStateTransferQueryDistributedIndexTest-NodeC-6067
> at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:199)
> at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 10 more
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-3006) Oracle: TableManipulation.tableExists fails, when user has extended permissions
by Thomas Fromm (JIRA)
[ https://issues.jboss.org/browse/ISPN-3006?page=com.atlassian.jira.plugin.... ]
Thomas Fromm updated ISPN-3006:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1759
> Oracle: TableManipulation.tableExists fails, when user has extended permissions
> --------------------------------------------------------------------------------
>
> Key: ISPN-3006
> URL: https://issues.jboss.org/browse/ISPN-3006
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.3.0.Alpha1
> Reporter: Thomas Fromm
> Assignee: Mircea Markus
> Priority: Minor
>
> When an Oracle user has e.g. permissions to visit other schemas, the metaData.getTables returns not only the table matadata of the schema of the current user. So if a table exists in another user it returns true.
> Solution: Since we anyway do not support explicit definition of schema name in configuration, we can use in case of oracle the current user name as schema pattern for getTables(..)
> Other databases has different structures, e.g. in mysql the schema param seems to be ignored. To avoid problems the chance should be limited to oracle at the moment.
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-3006) Oracle: TableManipulation.tableExists fails, when user has extended permissions
by Thomas Fromm (JIRA)
[ https://issues.jboss.org/browse/ISPN-3006?page=com.atlassian.jira.plugin.... ]
Thomas Fromm updated ISPN-3006:
-------------------------------
Affects Version/s: 5.3.0.Alpha1
Priority: Minor (was: Major)
Description:
When an Oracle user has e.g. permissions to visit other schemas, the metaData.getTables returns not only the table matadata of the schema of the current user. So if a table exists in another user it returns true.
Solution: Since we anyway do not support explicit definition of schema name in configuration, we can use in case of oracle the current user name as schema pattern for getTables(..)
Other databases has different structures, e.g. in mysql the schema param seems to be ignored. To avoid problems the chance should be limited to oracle at the moment.
Component/s: Loaders and Stores
> Oracle: TableManipulation.tableExists fails, when user has extended permissions
> --------------------------------------------------------------------------------
>
> Key: ISPN-3006
> URL: https://issues.jboss.org/browse/ISPN-3006
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 5.3.0.Alpha1
> Reporter: Thomas Fromm
> Assignee: Mircea Markus
> Priority: Minor
>
> When an Oracle user has e.g. permissions to visit other schemas, the metaData.getTables returns not only the table matadata of the schema of the current user. So if a table exists in another user it returns true.
> Solution: Since we anyway do not support explicit definition of schema name in configuration, we can use in case of oracle the current user name as schema pattern for getTables(..)
> Other databases has different structures, e.g. in mysql the schema param seems to be ignored. To avoid problems the chance should be limited to oracle at the moment.
--
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
11 years, 9 months
[JBoss JIRA] (ISPN-2822) Profile Infinispan when eviction enabled
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-2822?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-2822:
--------------------------------
Attachment: Unordered & None strategies.zip
the jprofiler snapshots for Unordered & none eviction strategies in case when no store is used.
> Profile Infinispan when eviction enabled
> ----------------------------------------
>
> Key: ISPN-2822
> URL: https://issues.jboss.org/browse/ISPN-2822
> Project: Infinispan
> Issue Type: Task
> Reporter: Martin Gencur
> Assignee: Anna Manukyan
> Fix For: 5.3.0.Final
>
> Attachments: config.xml, Eviction Profiling Results.pdf, File Store.zip, JDBC.zip, NO STORE.zip, Unordered & None strategies.zip
>
>
> Profile Infinispan for different eviction strategies (LRU, LIRS) and search for hot spots in the code (places where Infinispan spends most time when executing).
> Do this for two scenarios:
> 1) eviction enabled but no entries evicted (when the capacity is high)
> 2) eviction enabled and entries being evicted
--
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
11 years, 9 months