[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 commented on ISPN-3006:
------------------------------------
Honestly I've not tested if using schema prefix within table name prefix already is recognized by the Metadata.getTables. Maybe it simply already works, so in this case I've only to prepend the user name on my side and there is no change required. Let me test it first...
> 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, 2 months
[JBoss JIRA] (ISPN-3006) Oracle: TableManipulation.tableExists fails, when user has extended permissions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3006?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-3006:
---------------------------------------
Yes [~dan.berindei], this sounds like the most robust and compatible solution.
> 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, 2 months
[JBoss JIRA] (ISPN-3006) Oracle: TableManipulation.tableExists fails, when user has extended permissions
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3006?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3006:
------------------------------------
How about this: modify {{TableManipulation.tableExists()}} to split the table name on '.' and use the first part as the schema. That way we would restore the "support" we had for tables in other schemas prior to 5.2.
[~NadirX] what do you think?
> 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, 2 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 commented on ISPN-3006:
------------------------------------
Yes, add schema configuration would be a feature. By default schema of the current user is used, otherwise the configured schema.
At the moment the schema (at least for the sql statements) can be configured indirectly by adding the schema to the table name prefix. e.g. "KOSCH.ISPN_" This worked afaik until the table exists check was migrated to use of the Metadata.
I'd say lets fix the problem for now and create new Jira for the direct schema support.
> 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, 2 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:
----------------------------------
Here's a snippet of DEBUG log just before the exception:
13:13:36.694 [OOB-12,ISPN,xxx-46-22-46193] DEBUG org.infinispan.topology.LocalTopologyManagerImpl - Updating local consistent hash(es) for cache Foo.bar: new topology = CacheTopology{id=3, currentCH=ReplicatedConsistentHash{members=[xxx-46-16-22984]}, pendingCH=null}
13:13:36.698 [OOB-12,ISPN,xxx-46-22-46193] DEBUG org.infinispan.transaction.TransactionTable - Topology changed, recalculating minTopologyId
13:13:36.698 [OOB-15,ISPN,xxx-46-22-46193] DEBUG org.infinispan.topology.LocalTopologyManagerImpl - Starting local rebalance for cache Foo.bar, topology = CacheTopology{id=4, currentCH=ReplicatedConsistentHash{members=[xxx-46-16-22984]}, pendingCH=ReplicatedConsistentHash{members=[xxx-46-16-22984, xxx-46-22-46193]}}
13:13:36.700 [OOB-15,ISPN,xxx-46-22-46193] DEBUG org.infinispan.statetransfer.StateConsumerImpl - Removing state for segments [] of cache Foo.bar
13:13:36.700 [OOB-15,ISPN,xxx-46-22-46193] DEBUG org.infinispan.statetransfer.StateConsumerImpl - Removing L1 state for segments not in [0] or [] for cache Foo.bar
13:13:36.700 [OOB-15,ISPN,xxx-46-22-46193] DEBUG org.infinispan.statetransfer.StateConsumerImpl - Adding inbound state transfer for segments [0] of cache Foo.bar
13:13:36.700 [OOB-15,ISPN,xxx-46-22-46193] DEBUG org.infinispan.statetransfer.StateConsumerImpl - Finished adding inbound state transfer for segments [0] of cache Foo.bar
13:13:36.701 [OOB-15,ISPN,xxx-46-22-46193] DEBUG org.infinispan.transaction.TransactionTable - Topology changed, recalculating minTopologyId
13:17:36.704 [OOB-11,ISPN,xxx-46-22-46193] DEBUG org.infinispan.transaction.TransactionTable - Wait for on-going transactions to finish for 30 seconds.
13:17:36.705 [OOB-11,ISPN,xxx-46-22-46193] DEBUG org.infinispan.transaction.TransactionTable - All transactions terminated
13:17:36.712 [OOB-11,ISPN,xxx-46-22-46193] DEBUG org.infinispan.statetransfer.StateConsumerImpl - Finished receiving of segments for cache Foo.bar for topology 4.
13:17:36.713 [OOB-11,ISPN,xxx-46-22-46193] DEBUG org.infinispan.topology.LocalTopologyManagerImpl - Node xxx-46-22-461
13:17:36.720 [OOB-12,ISPN,xxx-46-22-46193] WARN org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher - Problems unmarshalling remote command from byte buffer
> 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, 2 months
[JBoss JIRA] (ISPN-3006) Oracle: TableManipulation.tableExists fails, when user has extended permissions
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3006?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3006:
------------------------------------
Thomas, if the user has permissions to see a table in another schema, why shouldn't we allow him to use that table for the cache store?
IMO we should add a "schema" attribute to the JDBC cache store configuration, but allow the user to put the table in any schema he has access to.
> 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, 2 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:
----------------------------------
Just before the exception there's also:
WARN org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher - Problems unmarshalling remote command from byte buffer
Don't know if related
> 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, 2 months