12:43 p.m.
I've sent this message erroneously to another thread... so I'm creating a
new and sending again.
Hey all,
I'm trying to figure out how to effectively use RHQ's dashboard as a main
view to a wall fixed monitor. I'm interested on showing the "Alerted or
Unavailable Resources" and "Platform Utilization" portlets side by side.
I've configured it like that and have been using a specific read only user
to keep the session (FIGURA1.png).
All works fine, but the issue is that the user session keeps expiring. I
referred to "https://bugzilla.redhat.com/show_bug.cgi?id=RHQ-2082" but the
"refresh interval" is already setted to "1 minute" and this do not
prevent
the session expiration, so the annoying user/pass modal window appears
after a while.
Meanwhile, to try to resolve that I built a simple HTML page that
periodically refreshes an iframe which refers to the dashboard's address,
but then I faced other issue: on the majority of refreshes instead of
showing the dashboard content it shows the "Globally Uncaught Exception"
error (FIGURA2.png).
Does someone knows how could one fix this expire session issue? Maybe some
setting on the RHQ server's configuration?
RHQ version: 4.1 on Ubuntu 10.04 LTS
Browser being tested: Firefox 10.0.1 (Windows and Linux, the error after
refresh issue happens on both).
HTML code for iframe:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt-br"
lang="pt-br">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<meta http-equiv="content-type" content="text/html; charset=utf-8"
/>
<meta http-Equiv="Cache-Control" Content="no-cache" />
<meta http-Equiv="Pragma" Content="no-cache" />
<meta http-Equiv="Expires" Content="0" />
<meta http-equiv="refresh" content="30" />
</head>
<body style="margin: 0px;">
<iframe name="myInnerFrame" id="innerframe" src="
http://rhq:7080/coregui/#Dashboards" style="width: 100%; height:
100%">O
Seo Browser da Dona Internet não suporta frames?</iframe>
</body>
</html>
Best regards.
Herbert
--
Herbert Mattei de Borba
herbertdeborba(a)gmail.com
12:59 p.m.
Herbert,
Not a direct answer to your question but we have built custom dashboards for our customers
using the Java api. Building a custom dashboard has the advantage that you can display
very specific metrics that are important to your application. For example we had a
dashboard showing the availability of all servers and specific queue counts and specific
row counts of my sql tables.
Hopefully the new REST api will make it possible to create really nice dashboards using
just HTML 5 and a bit of Javascript.
Steve Millidge
Director
C2B2
www.c2b2.co.uk
Sent from my BlackBerry® wireless device
-----Original Message-----
From: Herbert de Borba <herbertdeborba(a)gmail.com>
Sender: rhq-users-bounces(a)lists.fedorahosted.org
Date: Wed, 15 Feb 2012 16:43:41
To: <rhq-users(a)lists.fedorahosted.org>
Reply-To: rhq-users(a)lists.fedorahosted.org
Subject: Avoiding User's Session Timeout
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-users
2:28 p.m.
Steve,
Thanks for the suggestion. We could use customs dashboards in the future
but for now it would be awesome if we could successfully use the predefined
one, since there is no development characteristics on our department.
Regards.
2012/2/15 <smillidge(a)c2b2.co.uk>
Herbert,
Not a direct answer to your question but we have built custom dashboards
for our customers using the Java api. Building a custom dashboard has the
advantage that you can display very specific metrics that are important to
your application. For example we had a dashboard showing the availability
of all servers and specific queue counts and specific row counts of my sql
tables.
Hopefully the new REST api will make it possible to create really nice
dashboards using just HTML 5 and a bit of Javascript.
Steve Millidge
Director
C2B2
www.c2b2.co.uk
Sent from my BlackBerry® wireless device
2:58 p.m.
Ian,
The full stack trace is attached to this message.
I'd tried changing the url reference to "/coregui" and "/coregui/"
but
unfortunally the error persisted.
So it's 60 minutes the session expire time... Since the session will be
open for a read only user this might not be a so severe security problem. I
suppose that is not possible to change the timeout for only one user right
now but it is for the whole system? It might be an option for us.
Your suggestions are appreciated.
Thank you.
2012/2/15 Ian Springer <ian.springer(a)redhat.com>
Can you copy and paste the full stack trace of the Globally Uncaught
Exception into this thread? A lot of it got cut off on the right in the
screenshot you attached.
I think the issue might be here that we reset the GUI's session expiration
timer any time we detect the user navigating to a new "view" within the app
(views are designated by the #XXX portion of the URL). Doing a hard browser
refresh where the #XXX does not change might not count as a user navigation
and therefore not trigger a reset of the session timer. One thing you could
try is changing the URL of your iframe from <http://rhq:7080/coregui/#Dashboards>
http://rhq:7080/coregui/#Dashboards
to http://rhq:7080/coregui/ <http://rhq:7080/coregui/#Dashboards>;. This
might work because, you're switching from the view "Dashboards" to the
view "". And "" will "redirect" to "Dashboards"
anyway, so your console
would still work as desired. This is all theoretical though. Let me know if
you have any luck. If not, I may have some other ideas.
I would file a BZ for a new feature that allows an RHQ admin user to
disable the 60 min session timeout for a particular session after logging
in. Obviously, disabling the timeout could be seen as a security risk, so
we could display a confirmation dialog, e.g. "Are you sure you want to
disable session timeouts? This can be a security risk if the PC running RHQ
is left unattended."
--Ian
10:34 a.m.
Galera,
I found the "operation-timeout" on
"rhq-server/bin/rhq-server.properties"
file and adjust the global timeout there:
# Operations/controls timeout
# Defines the default timeout for all operations (specified in seconds)
rhq.server.operation-timeout=43200
I think it solved the problem for now, but it would be great if the issue
with refresh (Globally Uncaught Exception) could be explained and the
habilty to define a expiring time on a user basis also.
Regards.
Herbert
11:06 a.m.
On Thu, 2012-02-16 at 14:34 -0200, Herbert de Borba wrote:
I found the "operation-timeout" on
"rhq-server/bin/rhq-server.properties" file and adjust the global
timeout there:
# Operations/controls timeout
# Defines the default timeout for all operations (specified in
seconds)
rhq.server.operation-timeout=43200
For the record, that setting is for the server's default timeout when it
is invoking "operations" on the agent (i.e. this is for when executing
operations from the Operations tab). "Operations" have a distinct
semantic in RHQ - they are "operations" that plugins expose via the
<operation> metadata (OperationFacet to plugin developers) which execute
something on managed resources.
It doesn't involve GUI/session timeouts.
11:30 a.m.
You're right, user login popped up again.
Is there a way to do what I want?
Thanks
2012/2/16 John Mazzitelli <jmazzite(a)redhat.com>
On Thu, 2012-02-16 at 14:34 -0200, Herbert de Borba wrote:
> I found the "operation-timeout" on
> "rhq-server/bin/rhq-server.properties" file and adjust the global
> timeout there:
> # Operations/controls timeout
> # Defines the default timeout for all operations (specified in
> seconds)
> rhq.server.operation-timeout=43200
For the record, that setting is for the server's default timeout when it
is invoking "operations" on the agent (i.e. this is for when executing
operations from the Operations tab). "Operations" have a distinct
semantic in RHQ - they are "operations" that plugins expose via the
<operation> metadata (OperationFacet to plugin developers) which execute
something on managed resources.
It doesn't involve GUI/session timeouts.
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-users
--
Herbert Mattei de Borba
herbertdeborba(a)gmail.com
1:26 p.m.
I don't think there is a way to do what you want. The session timeout
is not currently configurable and was put in place for security reasons.
The only way to extend the session timer is to navigate to another view
or refresh the page.
But, the idea of having a dashboard stay available indefinitely seems
reasonable. Or, even a user session, if the user was granted some sort
of permission for permanent sessions.
I'd suggest creating a request for enhancement in bugzilla, or opening a
support case if you are a JON customer.
On 2/16/2012 12:30 PM, Herbert de Borba wrote:
You're right, user login popped up again.
Is there a way to do what I want?
Thanks
2012/2/16 John Mazzitelli <jmazzite(a)redhat.com
<mailto:jmazzite@redhat.com>>
On Thu, 2012-02-16 at 14:34 -0200, Herbert de Borba wrote:
> I found the "operation-timeout" on
> "rhq-server/bin/rhq-server.properties" file and adjust the global
> timeout there:
> # Operations/controls timeout
> # Defines the default timeout for all operations (specified in
> seconds)
> rhq.server.operation-timeout=43200
For the record, that setting is for the server's default timeout
when it
is invoking "operations" on the agent (i.e. this is for when executing
operations from the Operations tab). "Operations" have a distinct
semantic in RHQ - they are "operations" that plugins expose via the
<operation> metadata (OperationFacet to plugin developers) which
execute
something on managed resources.
It doesn't involve GUI/session timeouts.
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
<mailto:rhq-users@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/rhq-users
--
Herbert Mattei de Borba
herbertdeborba(a)gmail.com <mailto:herbertdeborba@gmail.com>
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-users
1:36 p.m.
Hi,
I just wanted to mention that RTI supports this capability. Sessions are
refreshed as needed within our remote access layer, and RHQ / JON
measurements can be plotted, overlaid across multiple platforms /
resources, and periodically refreshed on customized time ranges.
You might want to take a look and see if this meets your needs:
http://www.rtiperformance.com/resource-monitoring.
Thanks,
Steve
On Thu, Feb 16, 2012 at 2:26 PM, Jay Shaughnessy <jshaughn(a)redhat.com>wrote:
I don't think there is a way to do what you want. The session timeout is
not currently configurable and was put in place for security reasons. The
only way to extend the session timer is to navigate to another view or
refresh the page.
But, the idea of having a dashboard stay available indefinitely seems
reasonable. Or, even a user session, if the user was granted some sort of
permission for permanent sessions.
I'd suggest creating a request for enhancement in bugzilla, or opening a
support case if you are a JON customer.
On 2/16/2012 12:30 PM, Herbert de Borba wrote:
> You're right, user login popped up again.
>
> Is there a way to do what I want?
>
> Thanks
>
> 2012/2/16 John Mazzitelli <jmazzite(a)redhat.com <mailto:
> jmazzite(a)redhat.com>>
>
> On Thu, 2012-02-16 at 14:34 -0200, Herbert de Borba wrote:
>
> > I found the "operation-timeout" on
> > "rhq-server/bin/rhq-server.**properties" file and adjust the
global
> > timeout there:
>
> > # Operations/controls timeout
> > # Defines the default timeout for all operations (specified in
> > seconds)
> > rhq.server.operation-timeout=**43200
>
> For the record, that setting is for the server's default timeout
> when it
> is invoking "operations" on the agent (i.e. this is for when executing
> operations from the Operations tab). "Operations" have a distinct
> semantic in RHQ - they are "operations" that plugins expose via the
> <operation> metadata (OperationFacet to plugin developers) which
> execute
> something on managed resources.
>
> It doesn't involve GUI/session timeouts.
>
> ______________________________**_________________
> rhq-users mailing list
> rhq-users(a)lists.fedorahosted.**org <rhq-users(a)lists.fedorahosted.org>
>
<mailto:rhq-users@lists.**fedorahosted.org<rhq-users@lists.fedorahosted.org>
> >
>
https://fedorahosted.org/**mailman/listinfo/rhq-users<https://fedoraho...
>
>
>
>
> --
> Herbert Mattei de Borba
> herbertdeborba(a)gmail.com
<mailto:herbertdeborba@gmail.**com<herbertdeborba@gmail.com>
> >
>
>
>
> ______________________________**_________________
> rhq-users mailing list
> rhq-users(a)lists.fedorahosted.**org <rhq-users(a)lists.fedorahosted.org>
>
https://fedorahosted.org/**mailman/listinfo/rhq-users<https://fedoraho...
>
______________________________**_________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.**org <rhq-users(a)lists.fedorahosted.org>
https://fedorahosted.org/**mailman/listinfo/rhq-users<https://fedoraho...
--
Steve Sturtevant (v) (703) 577-6633
Product Manager, RTI *
Lightweight Performance Monitoring and Diagnostics*
http://www.rtiperformance.com/ <http://www.rtiperformance.com/download/>
1:44 p.m.
Ok, so. I'll try some workarounds, maybe a login robot, at least I'm
relieved that you don't put a captcha for security reasons :)
Thank you all.
Herbert.
2012/2/16 Jay Shaughnessy <jshaughn(a)redhat.com>
I don't think there is a way to do what you want. The session timeout is
not currently configurable and was put in place for security reasons. The
only way to extend the session timer is to navigate to another view or
refresh the page.
But, the idea of having a dashboard stay available indefinitely seems
reasonable. Or, even a user session, if the user was granted some sort of
permission for permanent sessions.
I'd suggest creating a request for enhancement in bugzilla, or opening a
support case if you are a JON customer.
2:16 p.m.
Yeah, I was thinking something like Selenium could be used to login and
then perform a page navigation every 50 minutes or so to keep the
session alive.
By the way, if you want to file an enhancement request, RHQ Bugzilla is
the place to do so:
https://bugzilla.redhat.com/page.cgi?id=browse.html&product=RHQ+Project
On 02/16/2012 02:44 PM, Herbert de Borba wrote:
Ok, so. I'll try some workarounds, maybe a login robot, at least
I'm
relieved that you don't put a captcha for security reasons :)
Thank you all.
Herbert.
2012/2/16 Jay Shaughnessy <jshaughn(a)redhat.com
<mailto:jshaughn@redhat.com>>
I don't think there is a way to do what you want. The session
timeout is not currently configurable and was put in place for
security reasons. The only way to extend the session timer is to
navigate to another view or refresh the page.
But, the idea of having a dashboard stay available indefinitely
seems reasonable. Or, even a user session, if the user was
granted some sort of permission for permanent sessions.
I'd suggest creating a request for enhancement in bugzilla, or
opening a support case if you are a JON customer.
_______________________________________________
rhq-users mailing list
rhq-users(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-users
--
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer(a)redhat.com
4477
days inactive
4478
days old
rhq-users@lists.fedorahosted.org
10 comments
6 participants
participants (6)
-
Herbert de Borba -
Ian Springer -
Jay Shaughnessy -
John Mazzitelli -
Steve Millidge -
Steve Sturtevant