[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back
by Werner Müller (JIRA)
[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ]
Werner Müller commented on RTGOV-645:
-------------------------------------
I did some investigations with the answer of (3). Thanks for reaching out to the forum. At the moment, it seems to me, as this would be the solution. But I still want to continue the investigations tomorrow. (There are some tricky constructs in our code.) Therefore, I don't want to give my final ok.
If this and (7) is solved, I agree with your understanding.
> Resubmitted message should identify source situation to enable further failures (situations) to be linked back
> --------------------------------------------------------------------------------------------------------------
>
> Key: RTGOV-645
> URL: https://issues.jboss.org/browse/RTGOV-645
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.1.0.Beta2
>
>
> When a message, associated with a situation, is resubmitted, ensure that the situation id is carried in a message header so that it can be included in resulting activity events.
> If the resubmitted message results in further situations being created, then these new situations should include the reference back to the originating situation id.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (RTGOV-645) Resubmitted message should identify source situation to enable further failures (situations) to be linked back
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-645?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-645:
----------------------------------
>From the forum thread for issue (3), it appears that currently the only solution is to provide a context mapper on the JMS binding, to map the RTGov property to the JMS message and then back again, within the second service.
Therefore once the minor issue (7) has been fixed, I believe all other further work is now associated with the other jiras. Can you confirm this is your understanding as well?
> Resubmitted message should identify source situation to enable further failures (situations) to be linked back
> --------------------------------------------------------------------------------------------------------------
>
> Key: RTGOV-645
> URL: https://issues.jboss.org/browse/RTGOV-645
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.1.0.Beta2
>
>
> When a message, associated with a situation, is resubmitted, ensure that the situation id is carried in a message header so that it can be included in resulting activity events.
> If the resubmitted message results in further situations being created, then these new situations should include the reference back to the originating situation id.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080
by Werner Müller (JIRA)
[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ]
Werner Müller commented on RTGOV-650:
-------------------------------------
Yes, I think that would be a feasible quick fix. As I understand, the URLs refer to the nodes in a cluster and would be selected randomly by the program. Does this also allow you to properly configure hetergeneous clusters?
May be you could combine the fixed list of URLs with your previous approach of using the switchyard registry in case a cluster is configured. In that case, we probably would need only one fixed URL for a standalone installation.
One additional idea: What about adding a combo box next to the Resubmit button? The list is populated with the URL list (fixed or from the registry), but the user still has the final decision - and even can enter another address. However, the combo box approach would fail for a bulk resubmit to different services on a heterogenous cluster (unless we have a "resubmit to original target address" option) ...
> A Situation is always resubmitted to localhost:8080
> ---------------------------------------------------
>
> Key: RTGOV-650
> URL: https://issues.jboss.org/browse/RTGOV-650
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Werner Müller
> Assignee: Gary Brown
>
> A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ]
Gary Brown edited comment on RTGOV-650 at 4/8/15 3:18 AM:
----------------------------------------------------------
Do you use the RTGov UI on a machine that is part of the switchyard cluster that is executing the services?
After some discussion with switchyard team, they suggested accessing the registry used by switchyard to obtain the relevant endpoint(s) - but this would only really work if the machine running RTGov UI was in a cluster with the machines running the services, so it could access the underlying infinispan cache used to store the registry info.
NOTE: The benefit of this approach is that it would resubmit to a currently running machine - whereas if the URL was stored in the activity information and then used, it may be out of date if the target machine is either down, or services have been migrated off of that machine, in the meantime.
was (Author: objectiser):
Do you use the RTGov UI on a machine that is part of the switchyard cluster that is executing the services?
After some discussion with switchyard team, they suggested accessing the registry used by switchyard to obtain the relevant endpoint(s) - but this would only really work if the machine running RTGov UI was in a cluster with the machines running the services, so it could access the underlying infinispan cache used to store the registry info.
> A Situation is always resubmitted to localhost:8080
> ---------------------------------------------------
>
> Key: RTGOV-650
> URL: https://issues.jboss.org/browse/RTGOV-650
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Werner Müller
> Assignee: Gary Brown
>
> A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months
[JBoss JIRA] (RTGOV-650) A Situation is always resubmitted to localhost:8080
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-650?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-650:
----------------------------------
Do you use the RTGov UI on a machine that is part of the switchyard cluster that is executing the services?
After some discussion with switchyard team, they suggested accessing the registry used by switchyard to obtain the relevant endpoint(s) - but this would only really work if the machine running RTGov UI was in a cluster with the machines running the services, so it could access the underlying infinispan cache used to store the registry info.
> A Situation is always resubmitted to localhost:8080
> ---------------------------------------------------
>
> Key: RTGOV-650
> URL: https://issues.jboss.org/browse/RTGOV-650
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Werner Müller
> Assignee: Gary Brown
>
> A Situation is always resubmitted to localhost:8080. Instead, it should be resubmitted to the original target address of the request.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 7 months