There shouldn't be any magic to the Teiid console. The 9990 port is exposed, correct? If the Teiid console is not installed, can you see the console? And do you even see the the default 8080 page?
I am not sure what I did wrong, after a rebuild, the webinterface is now up and running. Probably it simply got to late yesterday night However, I am not sure if the console does what it should. I found the docs here:
And thought that the console might be the right place to analyse my queries and the resulting source queries teiid generates (Section requests according to the old console documentation)
Unfortunately I only get Teiid Configuration infos and no runtime information, see screenshots below:
Is there some configuration oprion I am missing, or doesn't the console provide runtime information anymore on newer wildfly instances? Unfortunately, I have not found more up to date documentation on the teiid wildfly console yet.
Thanks for your help!
See the updated docs on the console: Teiid Console · GitBook with new screen captures. You would expect to see Teiid as one of the available subsystems to monitor in the runtime. If it's not there, perhaps you are have started in a non-Teiid configuration.
thanks for the link, this helped. The behavior was not easy to follow
If I use the link like in your provided description
than I get the interface,
If I use the default link via
I do not see the web console. Is this expected behavior or should I add a bug report?
I need to ask you once more to the topic. Even so I now have the console available, it does not show up any request or sessions. My queries are all made via odata protocol. Is there a further config option/ log level configuration needed to make diagnostics appear? The docu does not give hints on this. Thanks for your help.
> I do not see the web console. Is this expected behavior or should I add a bug report?
I'm not sure there's a bug. If I access this url when not in docker, I'm issued a redirect to console/App.html - is it possible that your browser is not following redirects?
> My queries are all made via odata protocol. Is there a further config option/ log level configuration needed to make diagnostics appear? The docu does not give hints on this.
No need for a hint - it should just work
On latest I'm seeing similar behavior. The pages seem fine initially, but don't seem to be picking up any runtime information, nor does the sql workbench run button seem to do anything. The console app doesn't use the admin api. It has it's own logic for drm interactions, so the issues probably lie there. Can you log something for this? I'll try to rebuild an updated console to see if that helps.
I have now verified that the session/request information actually does work as expected. Are you sure you are looking at the console when a request is actively executing?
What still work even with updating the console parent pom version is the sql workbench.
I do not understand your question
>>Are you sure you are looking at the console when a request is actively executing?
I have the following view open in the browser
At the same time I am sending queries from a second browser window via odata. Hence I would say yes, I am sure.
>> What still work even with updating the console parent pom version is the sql workbench.
I do not understand your recommendation.
In your first answer you wrote you have seen similar problems. How did you solve them?
Thanks for your help.
> At the same time I am sending queries from a second browser window via odata. Hence I would say yes, I am sure.
You may also need to hit refresh. Since these are odata queries, there is no connection pool being used. An embedded connection is created on demand and its corresponding session will end when the odata response is sent. You can also use JDBC to connect so that you can create a longer lasting session / query.
> I do not understand your recommendation.
That was not a recommendation for you, just a first step in seeing if there was some change that was needed to be picked up from a later parent pom. Based upon what I've seen, the answer is no.
> In your first answer you wrote you have seen similar problems. How did you solve them?
No changes. It seemed to be merely an issue of when the page was refreshing vs. when their was an active query/session.
I have refreshed the browser several times when doing so, and I was doing larger queries with reading about 500.000 records (loadtime in browser about 3s). However, I do not see anything in the web console. Do you have an idea how I can narrow down the problem? It is difficult to write efficient code for stored procedures without seeing what queries teiid generates from it.
> Do you have an idea how I can narrow down the problem?
Unfortunately no. I'm not sure what is causing the inconsistent behavior with the console.
Can you test with a JDBC client and see if you see anything?
Beyond that we'll likely need to start capturing exact browser versions.
> It is difficult to write efficient code for stored procedures without seeing what queries teiid generates from it.
Increasing logging on the server would be the best route.
Alternatively the adminapi can be used directly.
in this case I will wait for the next teiid version and hope that things will be gone there. I am still working with a custom Olingo build as Teiid overlay. Maybe this is causing the trouble. Otherwise I assume you would also see the issue. I have now tried Firefox, Chrome and Safari Browser, everywhere the same behavior.
> I am still working with a custom Olingo build as Teiid overlay
That shouldn't affect the console reporting.
> I have now tried Firefox, Chrome and Safari Browser, everywhere the same behavior.
It's very hard to say what's going on at this point. I will circle back locally to look at the workbench again. If you still can't get anything in the query/session panels via odata or jdbc queries, please start a JIRA issue.