Paul Richardson <p.g.richardson.uk> made a comment on jira TEIIDDES-1779 Given that JBT is declaring domain mode unsupported, its unsurprising that things are not working. See [https://issues.jboss.org/browse/JBIDE-14592]. I think until JBT has domain mode fully supported there is no way that designer's tools could reliably try and get it working.
Van Halbert <vhalbert> made a comment on jira TEIIDDES-1779 JBIDE-14592 is about trying to start and manage the server from eclipse. The issue I'm seeing is after externally starting the server, Designer has issues. And looking looking at the message, it appears Designer is not specifying the "domain" (ex., "ha") in its address that its calling.
Paul Richardson <p.g.richardson.uk> made a comment on jira TEIIDDES-1779 Spending time today looking at this, I have not repeated the error and in one case can go past where the error is produced. However, I get 2 different errors, depending on the server I try and configure in eclipse. Environment * falcon - jboss domain controller * goshawk - jboss slave (also localhost) Creating a server in the Servers view and starting the server (externally) is successful. Opening the server editor and doing an admin ping works but trying to do a jdbc ping fails. The actual exception is obscured but debugging I find the following occurs when the 'ping' vdb is being deployed: {code} org.teiid.adminapi.AdminProcessingException: TEIID70006 JBAS010849: Operation composite for address [] can only be handled by the master Domain Controller; this host is not the master Domain Controller {code} So I switched to falcon since its the domain controller. Unfortunately, the mileage is even less in that starting the server fails to create a teiid connection. In the console log I get the following: {code} java.lang.IllegalArgumentException at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:124) at org.jboss.dmr.ModelNode.keys(ModelNode.java:1194) at org.teiid.adminapi.AdminFactory$AdminImpl.getDomainAwareList(AdminFactory.java:1484) at org.teiid.adminapi.AdminFactory$AdminImpl.getVDBs(AdminFactory.java:1571) at org.teiid.adminapi.AdminFactory$AdminImpl.getVDBs(AdminFactory.java:1) at org.teiid84.runtime.ExecutionAdmin.refreshVDBs(ExecutionAdmin.java:660) at org.teiid84.runtime.ExecutionAdmin.init(ExecutionAdmin.java:577) at org.teiid84.runtime.ExecutionAdmin.<init>(ExecutionAdmin.java:137) at org.teiid84.runtime.ExecutionAdminFactory.createExecutionAdmin(ExecutionAdminFactory.java:32) at org.teiid.designer.runtime.registry.TeiidRuntimeRegistry.getExecutionAdmin(TeiidRuntimeRegistry.java:102) at org.teiid.designer.runtime.TeiidServer.connect(TeiidServer.java:217) at org.teiid.designer.runtime.TeiidServer.reconnect(TeiidServer.java:239) at org.teiid.designer.runtime.TeiidParentServerListener.serverChanged(TeiidParentServerListener.java:146) at org.eclipse.wst.server.core.internal.ServerNotificationManager.broadcastChange(ServerNotificationManager.java:125) at org.eclipse.wst.server.core.internal.Server.fireServerStateChangeEvent(Server.java:742) at org.eclipse.wst.server.core.internal.Server.setServerState(Server.java:650) at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.setServerState(ServerBehaviourDelegate.java:143) at org.jboss.ide.eclipse.as.core.server.internal.DeployableServerBehavior.setServerStarted(DeployableServerBehavior.java:210) at org.jboss.ide.eclipse.as.core.server.internal.DelegatingServerBehavior.setServerStarted(DelegatingServerBehavior.java:100) at org.jboss.ide.eclipse.as.rse.core.RSEJBossStartLaunchDelegate.preLaunchCheck(RSEJBossStartLaunchDelegate.java:44) at org.jboss.ide.eclipse.as.core.server.internal.launch.DelegatingStartLaunchConfiguration.preLaunchCheck(DelegatingStartLaunchConfiguration.java:67) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:813) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:707) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:700) at org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3537) at org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3473) at org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) {code} The domain aware list request is part of the teiid client so I would defer to their expertise first to understand why its occurring when fetching vdbs (of which there are none at this time).
Ramesh Reddy <rareddy> made a comment on jira TEIIDDES-1779 Last time I saw that message because of Admin connection was not created with the correct domain profile name and AS folks changed the return result JSON structure between versions on us than what was written for the parsing routine. I suspect something similar, you should be able to walk the code in debug and see what is going on.
Paul Richardson <p.g.richardson.uk> made a comment on jira TEIIDDES-1779 More debugging (as suggested) and I have found the issue. It seems that the jboss devs changed the default 'ha' profile to 'full-ha' (see yellow note [here|https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto]). Since designer never changes the profile name due to no provision in the UI, the original 'ha' is preserved hence the subsystem path requested by the 'request' is invalid. Once I replace 'ha' with 'full-ha' in the code I get a connection. However ... still cannot ping via jdbc. Oddly, despite making all loggers in domain.xml have a level of DEBUG, I cannot get out any more information. {code} 16:53:13,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "ping-vdb.xml" (runtime-name: "ping-vdb.xml") 16:53:13,560 WARN [org.teiid.RUNTIME] (MSC service thread 1-1) TEIID50077 The translator type "loopback" was not found in configuration; VDB ping.1 will not be started until translator is available. 16:53:13,788 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018559: Deployed "ping-vdb.xml" (runtime-name : "ping-vdb.xml") 16:53:14,181 WARN [org.teiid.SECURITY] (New I/O worker #2) TEIID40011 Processing exception 'TEIID40046 VDB "ping" version "latest" does not exist.' for session null. Exception type org.teiid.client.security.LogonException thrown from org.teiid.services.SessionServiceImpl.getActiveVDB(SessionServiceImpl.java:259). Enable more detailed logging to see the entire stacktrace. 16:53:14,412 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ping-vdb.xml (runtime-name: ping-vdb.xml) in 43ms 16:53:14,545 INFO [org.jboss.as.repository] (host-controller-connection-threads - 1) JBAS014901: Content removed from location /home/jboss/jboss-7.1/domain/servers/server-one/data/content/fc/f324141fb233a0401624dc0982576eb4a8fed2/content 16:53:14,546 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018558: Undeployed "ping-vdb.xml" (runtime-name: "ping-vdb.xml") {code} I suspect its a config issue but I have 'user' in teiid-security-users.properties and slave under mgmt-users.properties. Maybe, teiid-security-users.properties is not being used?
Van Halbert <vhalbert> made a comment on jira TEIIDDES-1779 Do we need to add an enhancement to enable changing the profile? Since we'll hit this issue immediately.
Van Halbert <vhalbert> made a comment on jira TEIIDDES-1779 Do we need to add an enhancement to enable changing the profile? Since we'll hit this issue immediately. Maybe the profile can be determined from the remote server connection that was made, when it was pointed to the configuration that was used.
Ramesh Reddy <rareddy> made a comment on jira TEIID-2650 Runtime version and Active Sessions are added as Runtime attributes of the Teiid Subsystem, so they are not part of the configuration like other attributes you see with the "read-resource". So, in the domain mode when you make a call {code} /profile=ha/subsystem=teiid:read-resource {code} it will only returns the configurable attributes. However, if you issue the command against a running node server like {code} /host=master/server=server-one/subsystem=teiid:read-resource {code} it will return right results, however there seems to another bug in AS code that is not being reported correctly. I see the invocations correctly. however, the correct way to look for attribute is to {code} /host=master/server=server-one/subsystem=teiid:read-attribute(name=runtime-version) {code} That does work! So, there is nothing Teiid can fix I can think of, unless we make this property static in the standalone.xml or domain.xml. The idea in AS is each server node could possibly running a different Teiid subsystem. Designer needs to probe first for available hosts, then select one, then probe for available servers under that group, then use equivalent to above to get the right version.
Ramesh Reddy <rareddy> made a comment on jira TEIID-2650 Based on the above comment can this be marked as resolved?
Paul Richardson <p.g.richardson.uk> made a comment on jira TEIID-2650 Spent time creating queries through the domain master's client(?) servers and this works well. Thanks for the info. However, I do not see why the teiid runtime version is only available through these client servers. Since teiid is deployed onto the domain master rather than its client servers, I don't understand why the runtime version is not available in the location '/profile=ha/subsystem=teiid/runtime-version'. I realise its not a static property and has no place in the config files yet it is filled in correctly when the server is in standalone mode. It seems wrong that its 'undefined' for domain mode when we deploy teiid using the domain master. Maybe, I am still misunderstanding domain mode?
Brian Stansberry <brian.stansberry> made a comment on jira TEIID-2650 When you call {code} /profile=ha/subsystem=teiid:read-resource {code} you are asking the Host Controller you connected to for information about the *domain wide* configuration. The Host Controller could fill in information for runtime-version that is correct for it's own process, but it cannot provide information that's correct domain wide. There is no such thing as a domain wide runtime-version because it is perfectly legal to run multiple different versions on different hosts in a domain. It isn't required, or even expected in large domains, for all hosts to be on the same version. For example, different server groups might be running different applications, and if the behavior of some of those apps is acceptable domain managers may choose not to upgrade the hosts for those server groups when a new release comes out. Organizations are often quite conservative in this regard.
Brian Stansberry <brian.stansberry> made a comment on jira TEIID-2650 Note that the Teiid subsystem should not be registering this attribute on host controllers, since those processes cannot provide the information. When the Teiid Extension is initialized by the Host Controller, an ExtensionContext is passed in. ExtensionContenxt.getProcessType() allows the extension to know what type of process it is running in (DOMAIN_SERVER, EMBEDDED_SERVER, STANDALONE_SERVER, HOST_CONTROLLER, APPLICATION_CLIENT) so it can use that information to control what resources/attributes/operations it registers. Items that don't make sense for the given process type shouldn't be registered.
Ramesh Reddy <rareddy> made a comment on jira TEIID-2650 Brian, what would be the difference between DOMAIN_SERVER and STANDALONE_SERVER ? Are they both nodes?
Paul Richardson <p.g.richardson.uk> made a comment on jira TEIID-2650 Brian, Many thanks for that helpful information. It raises an interesting question though. In order to get teiid up and running, I use the [teiid-domain-mode-install.cli|https://docs.jboss.org/author/display/teiid84final/Installation+Guide] script to install the teiid resources on the domain master. Thus, I think that would constitute domain-wide would it not? Certainly, my domain member server inherits the teiid configuration from the domain master. It would seem that teiid is not merely a single application that is only deployed on member servers and in that sense 1 teiid configuration per domain?
Brian Stansberry <brian.stansberry> made a comment on jira TEIID-2650 Paul, To be precise, there is one *set* of Teiid configurations per domain. Different profiles in the domain can have different Teiid configurations. But yes, it is the responsibility of the domain management infrastructure to keep the domain wide configuration consistent across all Host Controllers in the domain, and that will include any Teiid subsystem configurations that exist. The Host Controllers ensure that servers gets a consistent representation of whatever portion of the domain wide config is relevant to that server. Configuration is distinct from runtime state though. The actual binaries installed on different hosts can be different, and this runtime-version attribute reflects what actual binaries are being used for a process. That doc, before getting into the teiid-domain-mode-install.cli script part, says "To start the server in "Domain" mode, install the JBoss AS 7.2 (EAP 6.1) and Teiid 8.4 on all the servers that are going to be part of the cluster." So there's a binary provisioning step that occurs before config gets applied. That doc focuses on an initial setup case where all hosts are almost certainly going to be running the same release. But once a domain is in active use, it's possible that some hosts will be upgraded to a later release while others will not.
Brian Stansberry <brian.stansberry> made a comment on jira TEIID-2650 Ramesh, Yes, DOMAIN_SERVER and STANDALONE_SERVER are both application server process types, as is EMBEDDED_SERVER. The distinctions reflect how the server lifecycle is controlled: DOMAIN_SERVER -- separate process controlled by the HostController STANDALONE_SERVER -- separate process controlled by the end user, typically via a launch script but not always, e.g. an Arquillian container could be managing the process programatically. But it's a separate process from the Arquillian container. EMBEDDED_SERVER -- server is running inside another process
Paul Richardson <p.g.richardson.uk> made a comment on jira TEIID-2650 I think that the upgrading of teiid on a domain member server to a different version of teiid to that on the domain master would be detrimental, would it not? For example, a new version of teiid might add a new translator or change its name and since this would be different from the master this would introduce a conflict. Therefore, is it best to declare that teiid installations should remain uniform across a domain? Ramesh, what do you think?
Paul Richardson <p.g.richardson.uk> made a comment on jira TEIID-2650 I think that the upgrading of teiid on a domain member server to a different version of teiid to that on the domain master would be detrimental, would it not? For example, a new version of teiid might add a new translator or change its name and since this would be different from the master this would introduce a conflict. Therefore, is it best to declare that teiid installations should remain uniform within profiles across a domain, ie. different teiid configurations in different profiles across a domain? Ramesh, what do you think?
Ramesh Reddy <rareddy> made a comment on jira TEIID-2650 Paul, that would be recommendation to the users/customers, but Brian is talking about capabilities and possibilities, so we need to take those into account. I will fix code such that runtime properties are not visible at configuration level.
Ramesh Reddy <rareddy> updated the status of jira TEIID-2650 to Resolved
Ramesh Reddy <rareddy> made a comment on jira TEIID-2650 Added both "runtime-version" and "session-count" as metrics, (read only attributes). Now they do not show up when you use :read-resource, you would need to get by [address]/subsystem=teiid:read-attribute(name=runtime-version)
Brian Stansberry <brian.stansberry> made a comment on jira TEIID-2650 Paul, you're not allowed to upgrade a host to a version later than the master. This is because the master has to be able to understand all configuration options and intra-domain communication protocols supported by any of the hosts. But, you are not required to upgrade all hosts when you upgrade the master. I do recommend that all servers in a server group be running on the same version, except for during short windows during a rolling upgrade. That's general advice, not anything specific to Teiid.
Van, Please review the Doc Text for this and add a workaround if one exists. Cheers, Ben
Steven Hawkins <shawkins> updated the status of jira TEIID-2650 to Closed
I just bumped into this accidently. First time I've heard about Teiid requesting/needing custom domain server support. Could we get some details on what you need from us ?
Barry LaFond <blafond> updated the status of jira TEIIDDES-1779 to Closed
Van Halbert <vhalbert> updated the status of jira JBDVPL-58 to Closed