May 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Resolved: (TEIID-244) Salesforce Connector should offer the abilty to query about object deletions.

by John Doyle (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-244?page=com.atlassian.jira.plug... ] John Doyle resolved TEIID-244. ------------------------------ Resolution: Done Revision 258 Added the models for getUpdated and getDeleted > Salesforce Connector should offer the abilty to query about object deletions. > ----------------------------------------------------------------------------- > > Key: TEIID-244 > URL: https://jira.jboss.org/jira/browse/TEIID-244 > Project: Teiid > Issue Type: Feature Request > Components: Salesforce Connector > Affects Versions: 6.0.0 > Reporter: John Doyle > Assignee: John Doyle > Fix For: 6.1.0 > > > Genentech wants to materialize lots of SalesForce data in Oracle, to speed up their reporting query times. It makes a significant difference because SFDC does not support joins, whereas Oracle does. Wanting the best of both worlds, they also want the data to be as fresh as possible -- ideally, the mat views would be no more than 10 minutes out-of-sync with the live data. > The amount of data in SalesForce already takes 20+ minutes to cache, and it will slowly grow over time. So, the current materialization process will not meet the cache coherence (freshness) requirement, since the data will be stale by the time the staging table is populated and swapped in. > How would you speed it up? > .......response.... > I actually put together a custom materialization script > (attached,with doc and sample config file) for Credit Suisse for doing > these sorts of partial refreshes. It is Oracle-specific, but since > that is what you are doing too it should work for you too. > However, the use case at Credit Suisse was for doing these partial > refreshes nightly, with full refreshes done weekly. There is (just as > with our standard materialization scripts) a short period (when the > table names are being swapped) when the materialization won't be stable > (queries could fail or return unexpected results). I don't know if > that makes it not suitable for doing 10 minute refreshes. > I would recommend instead using the materialization only for historical > data (from overnight materialization run), and unioning it to the live > data for the newer stuff. That is, query SFDC only for data where > createdDate or LastModifiedDate = today, and union that with the > current data. Two issues you'd need to deal with in your logic: > -if the same record is retrieved from both sources (meaning it was an > existing record that had been modified today), the historical record > should be discarded in favor of the live one. > -deleted records - how to detect records that were deleted today? If > you could ask SFDC exactly what was deleted today that would be great, > but that is probably wishful thinking. So failing that you would need > to ask SFDC for the keys for all live records, and then discard from > the historical data any records with keys not on that list. Or, you > could just live with having the deleted records in the view for an > extra day... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-575) MMx server should be started 'headless' to prevent AWT prompts

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-575?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-575. ---------------------------------- Resolution: Done Added to the config's default process launch command > MMx server should be started 'headless' to prevent AWT prompts > -------------------------------------------------------------- > > Key: TEIID-575 > URL: https://jira.jboss.org/jira/browse/TEIID-575 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > > Per https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&ti... customer request. > The JT400 JDBC driver (JTOpen) prompts the user with an AWT form when the credentials fail. When this happens, it blocks the MMx server thread until one remotes over to it graphically and enters the password. When one repeatedly ignores the prompt, typically DB2 disables the userid. This is time-consuming and it happens periodically. Although this is really JT400 braindamage, it points out that MMx appears not to be started in "headless" mode. To do this, do: > java -Djava.awt.headless=true > This should cause AWT prompts like this from JDBC drivers to go to the log as exceptions. See http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ for more info. > If you could just enter this as a bug/feature request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-575) MMx server should be started 'headless' to prevent AWT prompts

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-575?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-575: --------------------------------- Fix Version/s: 6.1.0 (was: 6.1.1) > MMx server should be started 'headless' to prevent AWT prompts > -------------------------------------------------------------- > > Key: TEIID-575 > URL: https://jira.jboss.org/jira/browse/TEIID-575 > Project: Teiid > Issue Type: Feature Request > Components: Server > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Priority: Minor > Fix For: 6.1.0 > > > Per https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&ti... customer request. > The JT400 JDBC driver (JTOpen) prompts the user with an AWT form when the credentials fail. When this happens, it blocks the MMx server thread until one remotes over to it graphically and enters the password. When one repeatedly ignores the prompt, typically DB2 disables the userid. This is time-consuming and it happens periodically. Although this is really JT400 braindamage, it points out that MMx appears not to be started in "headless" mode. To do this, do: > java -Djava.awt.headless=true > This should cause AWT prompts like this from JDBC drivers to go to the log as exceptions. See http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ for more info. > If you could just enter this as a bug/feature request. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-609) Finish shown initially in new connector binding wizard

by Steven Hawkins (JIRA)

Finish shown initially in new connector binding wizard ------------------------------------------------------ Key: TEIID-609 URL: https://jira.jboss.org/jira/browse/TEIID-609 Project: Teiid Issue Type: Bug Components: Console Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.1.1 Finish shown initially in new connector binding wizard. Next is expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
1
0 / 0

[JBoss JIRA] Resolved: (TEIID-420) VDB Deployment buttons are activated for Product Admin but error is produced on final Finish

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-420?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-420. ---------------------------------- Resolution: Done added a check for system admin to enable the import action > VDB Deployment buttons are activated for Product Admin but error is produced on final Finish > -------------------------------------------------------------------------------------------- > > Key: TEIID-420 > URL: https://jira.jboss.org/jira/browse/TEIID-420 > Project: Teiid > Issue Type: Bug > Components: Console > Affects Versions: 6.0.0 > Environment: Windows client against Windows server with Entitlements turned on > Reporter: Warren Gibson > Assignee: Steven Hawkins > Fix For: 6.1.1 > > Attachments: console_Log.log > > > Logged in as a Product Admin user and attempted to deploy a VDB. Everything worked fine until the final Finish button when an error was produced. > [AuthorizationException] ERR.014.001.0008: The client is not authorized to attempt this operation. User: SessionToken[pjones@MyLDAP,3653,slntmm05_15301] Role: Admin.SystemAdmin > at com.metamatrix.platform.admin.apiimpl.AdminHelper.checkForRequiredRole(AdminHelper.java:102) > at com.metamatrix.platform.admin.apiimpl.AdminAPIHelper.checkForRequiredRole(AdminAPIHelper.java:71) > at com.metamatrix.platform.admin.apiimpl.ConfigurationAdminAPIImpl.checkPropertiesDecryptable(ConfigurationAdminAPIImpl.java:1254) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.metamatrix.core.proxy.ServiceInvocation.invokeOn(ServiceInvocation.java:91) > at com.metamatrix.core.proxy.DefaultTerminalServiceInterceptor.invoke(DefaultTerminalServiceInterceptor.java:29) > at com.metamatrix.core.proxy.SecureTerminalServiceInterceptor.invoke(SecureTerminalServiceInterceptor.java:45) > at com.metamatrix.core.proxy.ServiceInvocation.invokeNext(ServiceInvocation.java:87) > at com.metamatrix.core.proxy.ServerSecurityServiceInterceptor.invoke(ServerSecurityServiceInterceptor.java:23) > at com.metamatrix.core.proxy.ServiceInvocation.invokeNext(ServiceInvocation.java:87) > at com.metamatrix.common.comm.platform.server.MessageServiceAgent.receiveLocal(MessageServiceAgent.java:90) > at com.metamatrix.common.comm.platform.server.MessageServiceAgent.receive(MessageServiceAgent.java:114) > at com.metamatrix.common.comm.platform.server.MessageFilterServiceAgent.receive(MessageFilterServiceAgent.java:99) > at com.metamatrix.platform.admin.apiimpl.RuntimeStateListenerAgent.receive(RuntimeStateListenerAgent.java:103) > at com.metamatrix.common.comm.platform.socket.SocketVMController.receive(SocketVMController.java:388) > at com.metamatrix.common.comm.platform.socket.server.ServerSynchronousWorkItem.process(ServerSynchronousWorkItem.java:36) > at com.metamatrix.common.comm.platform.socket.server.SocketServerWorker.process(SocketServerWorker.java:35) > at com.metamatrix.common.queue.QueueWorker.run(QueueWorker.java:64) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-420) VDB Deployment buttons are activated for Product Admin but error is produced on final Finish

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-420?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-420: --------------------------------- Assignee: Steven Hawkins Complexity: Low > VDB Deployment buttons are activated for Product Admin but error is produced on final Finish > -------------------------------------------------------------------------------------------- > > Key: TEIID-420 > URL: https://jira.jboss.org/jira/browse/TEIID-420 > Project: Teiid > Issue Type: Bug > Components: Console > Affects Versions: 6.0.0 > Environment: Windows client against Windows server with Entitlements turned on > Reporter: Warren Gibson > Assignee: Steven Hawkins > Fix For: 6.1.1 > > Attachments: console_Log.log > > > Logged in as a Product Admin user and attempted to deploy a VDB. Everything worked fine until the final Finish button when an error was produced. > [AuthorizationException] ERR.014.001.0008: The client is not authorized to attempt this operation. User: SessionToken[pjones@MyLDAP,3653,slntmm05_15301] Role: Admin.SystemAdmin > at com.metamatrix.platform.admin.apiimpl.AdminHelper.checkForRequiredRole(AdminHelper.java:102) > at com.metamatrix.platform.admin.apiimpl.AdminAPIHelper.checkForRequiredRole(AdminAPIHelper.java:71) > at com.metamatrix.platform.admin.apiimpl.ConfigurationAdminAPIImpl.checkPropertiesDecryptable(ConfigurationAdminAPIImpl.java:1254) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.metamatrix.core.proxy.ServiceInvocation.invokeOn(ServiceInvocation.java:91) > at com.metamatrix.core.proxy.DefaultTerminalServiceInterceptor.invoke(DefaultTerminalServiceInterceptor.java:29) > at com.metamatrix.core.proxy.SecureTerminalServiceInterceptor.invoke(SecureTerminalServiceInterceptor.java:45) > at com.metamatrix.core.proxy.ServiceInvocation.invokeNext(ServiceInvocation.java:87) > at com.metamatrix.core.proxy.ServerSecurityServiceInterceptor.invoke(ServerSecurityServiceInterceptor.java:23) > at com.metamatrix.core.proxy.ServiceInvocation.invokeNext(ServiceInvocation.java:87) > at com.metamatrix.common.comm.platform.server.MessageServiceAgent.receiveLocal(MessageServiceAgent.java:90) > at com.metamatrix.common.comm.platform.server.MessageServiceAgent.receive(MessageServiceAgent.java:114) > at com.metamatrix.common.comm.platform.server.MessageFilterServiceAgent.receive(MessageFilterServiceAgent.java:99) > at com.metamatrix.platform.admin.apiimpl.RuntimeStateListenerAgent.receive(RuntimeStateListenerAgent.java:103) > at com.metamatrix.common.comm.platform.socket.SocketVMController.receive(SocketVMController.java:388) > at com.metamatrix.common.comm.platform.socket.server.ServerSynchronousWorkItem.process(ServerSynchronousWorkItem.java:36) > at com.metamatrix.common.comm.platform.socket.server.SocketServerWorker.process(SocketServerWorker.java:35) > at com.metamatrix.common.queue.QueueWorker.run(QueueWorker.java:64) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-607) Connectors with invalid connection properties should show Source Unavailable at startup

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-607?page=com.atlassian.jira.plug... ] Steven Hawkins moved JBEDSP-798 to TEIID-607: --------------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-607 (was: JBEDSP-798) Component/s: Server (was: Server) Fix Version/s: 6.1.1 (was: Westport) Affects Version/s: 6.0.0 (was: 5.5.3) > Connectors with invalid connection properties should show Source Unavailable at startup > --------------------------------------------------------------------------------------- > > Key: TEIID-607 > URL: https://jira.jboss.org/jira/browse/TEIID-607 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 6.0.0 > Environment: MMServer: Fedora 8 Kernel 2.6.26.6-49.fc8 > Connector: Oracle JDBC Connector > Reporter: Larry O'Leary > Fix For: 6.1.1 > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > If invalid connection properties are used in a connector binding the connector status shows "Running" at startup of the connector. When the first query is executed against the MMSystem that needs this connector an exception is thrown indicating that the connector wasn't found. This is due to the connector state changing to "Data Source Unavailable". > Although this is the expected behavior it is very mis-leading to the administrator after creating/adding a new connector or bouncing the system. The MMConsole gives the appearance that everything is okay until users actually start running queries. > What should be occurring is the current behavior and if Data Source Monitoring is enabled on the connector we should then check the data source available during connector startup. In other words, start the monitor thread with a timer of 0 instead a timer of monitoring interval. The idea is to show the connector as "Data Source Unavailable" at connector startup if the source isn't can't be reached due to invalid connection properties. > TEST: > To test this issue you simply need to have a connector deployed to a running MMSystem and verify that it is actually starting correctly with correct properties (ie verify you can run queries using this connector). > Now, change the password on the connector to something that is invalid. Stop and then start the connector. The connector will show a "Running" state yet as soon as you execute the query the query will fail and the status of the connector will change to "Source Unavailable". > EXPECTED RESULT: > When you start a connector using an invalid password (or other connection type property like SID, DatabaseName, etc) the connector state should immediately reflect "Data Source Unavailable". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-604) Do not throw exception when ending transaction with TMFAIL

by Li Liang (JIRA)

Do not throw exception when ending transaction with TMFAIL ---------------------------------------------------------- Key: TEIID-604 URL: https://jira.jboss.org/jira/browse/TEIID-604 Project: Teiid Issue Type: Bug Affects Versions: 6.0.0, 6.1.0 Reporter: Li Liang Assignee: Li Liang Fix For: 6.1.0 >From customer case 289126. When Metamatrix participates in global transaction, if XAResource.end is called with TMFAIL, the transaction is set to be roll-back only and an XAException is thrown to indicate the changes. However, weblogic transaction manager does not expect the exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
1
0 / 0

[JBoss JIRA] Resolved: (TEIID-603) New LDAP membership provider ignored by server

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-603?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-603. ---------------------------------- Resolution: Done corrected the refactoring to use common property key definitions to actually use the same key. > New LDAP membership provider ignored by server > ---------------------------------------------- > > Key: TEIID-603 > URL: https://jira.jboss.org/jira/browse/TEIID-603 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 6.1.0 > Environment: Fedora 10 > Reporter: Paul Nittel > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 6.1.0 > > > Using the Console and Server from May 13, 2009, I added a new LDAP membership provider. After bouncing he server, I tried to access the new provider from the Admin Roles page. The provider combo box was empty (in prior versions, the provider would be listed, even if it were incorrectly defined and inaccessible). > I checked the process log files and there is no mention of the provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-603) New LDAP membership provider ignored by server

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-603?page=com.atlassian.jira.plug... ] Steven Hawkins moved JBEDSP-1043 to TEIID-603: ---------------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-603 (was: JBEDSP-1043) Component/s: Server (was: Server) Affects Version/s: 6.1.0 (was: Westport) > New LDAP membership provider ignored by server > ---------------------------------------------- > > Key: TEIID-603 > URL: https://jira.jboss.org/jira/browse/TEIID-603 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 6.1.0 > Environment: Fedora 10 > Reporter: Paul Nittel > Assignee: Steven Hawkins > Fix For: 6.1.0 > > > Using the Console and Server from May 13, 2009, I added a new LDAP membership provider. After bouncing he server, I tried to access the new provider from the Admin Roles page. The provider combo box was empty (in prior versions, the provider would be listed, even if it were incorrectly defined and inaccessible). > I checked the process log files and there is no mention of the provider. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2009