Bug 982741 - Designer unable to connect to remote server that's running in domain mode
Designer unable to connect to remote server that's running in domain mode
Status: CLOSED DEFERRED
Product: JBoss Data Virtualization 6
Classification: JBoss
Component: Teiid, Tooling (Show other bugs)
6.0.0
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Van Halbert
:
Depends On:
Blocks: 1006971
  Show dependency treegraph
 
Reported: 2013-07-09 14:08 EDT by Van Halbert
Modified: 2015-08-07 14:59 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When JBoss Data Virtualization is running on an instance of JBoss EAP in domain mode, Teiid Designer is unable to read the configuration.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-01 08:59:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBDVPL-58 Major Closed Support connecting from Designer to EAP Domain Mode 2017-06-02 08:07 EDT
JBoss Issue Tracker TEIID-2650 Blocker Closed A jboss server in domain mode does not advertise its teiid runtime-version 2017-06-02 08:07 EDT
JBoss Issue Tracker TEIIDDES-1779 Blocker Closed Designer error when trying to read a remote server configuration that's running in domain mode 2017-06-02 08:07 EDT

  None (edit)
Comment 2 JBoss JIRA Server 2013-07-16 08:05:48 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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.
Comment 3 JBoss JIRA Server 2013-08-12 16:44:28 EDT
Van Halbert <vhalbert@jboss.org> 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.
Comment 4 JBoss JIRA Server 2013-09-04 10:15:35 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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).
Comment 5 JBoss JIRA Server 2013-09-04 10:55:40 EDT
Ramesh Reddy <rareddy@jboss.org> 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.
Comment 6 JBoss JIRA Server 2013-09-04 11:58:54 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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?
Comment 7 JBoss JIRA Server 2013-09-04 14:35:36 EDT
Van Halbert <vhalbert@jboss.org> 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.
Comment 8 JBoss JIRA Server 2013-09-04 14:44:55 EDT
Van Halbert <vhalbert@jboss.org> 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.
Comment 11 JBoss JIRA Server 2013-09-05 14:17:36 EDT
Ramesh Reddy <rareddy@jboss.org> 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.
Comment 12 JBoss JIRA Server 2013-09-06 13:22:33 EDT
Ramesh Reddy <rareddy@jboss.org> made a comment on jira TEIID-2650

Based on the above comment can this be marked as resolved?
Comment 13 JBoss JIRA Server 2013-09-09 12:31:58 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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?
Comment 14 JBoss JIRA Server 2013-09-10 09:18:30 EDT
Brian Stansberry <brian.stansberry@redhat.com> 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.
Comment 15 JBoss JIRA Server 2013-09-10 09:24:21 EDT
Brian Stansberry <brian.stansberry@redhat.com> 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.
Comment 16 JBoss JIRA Server 2013-09-10 09:29:31 EDT
Ramesh Reddy <rareddy@jboss.org> made a comment on jira TEIID-2650

Brian, what would be the difference between DOMAIN_SERVER and STANDALONE_SERVER ? Are they both nodes?
Comment 17 JBoss JIRA Server 2013-09-10 09:58:30 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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?
Comment 18 JBoss JIRA Server 2013-09-10 10:39:01 EDT
Brian Stansberry <brian.stansberry@redhat.com> 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.
Comment 19 JBoss JIRA Server 2013-09-10 10:46:29 EDT
Brian Stansberry <brian.stansberry@redhat.com> 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
Comment 20 JBoss JIRA Server 2013-09-10 11:03:07 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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?
Comment 21 JBoss JIRA Server 2013-09-10 11:05:17 EDT
Paul Richardson <p.g.richardson@phantomjinx.co.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?
Comment 22 JBoss JIRA Server 2013-09-10 11:09:06 EDT
Ramesh Reddy <rareddy@jboss.org> 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.
Comment 23 JBoss JIRA Server 2013-09-10 13:04:58 EDT
Ramesh Reddy <rareddy@jboss.org> updated the status of jira TEIID-2650 to Resolved
Comment 24 JBoss JIRA Server 2013-09-10 13:04:58 EDT
Ramesh Reddy <rareddy@jboss.org> 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)
Comment 25 JBoss JIRA Server 2013-09-10 14:40:32 EDT
Brian Stansberry <brian.stansberry@redhat.com> 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.
Comment 30 belong 2013-11-15 00:10:45 EST
Van,

Please review the Doc Text for this and add a workaround if one exists.

Cheers,
Ben
Comment 31 JBoss JIRA Server 2013-12-05 15:52:13 EST
Steven Hawkins <shawkins@redhat.com> updated the status of jira TEIID-2650 to Closed
Comment 34 Max Rydahl Andersen 2014-10-06 08:28:51 EDT
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 ?
Comment 35 JBoss JIRA Server 2015-03-31 09:59:03 EDT
Barry LaFond <blafond@jboss.org> updated the status of jira TEIIDDES-1779 to Closed
Comment 36 JBoss JIRA Server 2015-08-07 14:59:06 EDT
Van Halbert <vhalbert@jboss.org> updated the status of jira JBDVPL-58 to Closed

Note You need to log in before you can comment on or make changes to this bug.