[
https://issues.apache.org/jira/browse/NIFI-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022164#comment-17022164
]
Nagasivanath Dasari commented on NIFI-7056:
-------------------------------------------
As per me, it would be to good to prevent the user from allowing to invoke the
action, by creating a mask div and dispaying a loading status. but this
behaviour should be consistent across all the features. as this is a big
change, we need a JIRA.
_*To handle the above case, we can clear the existing variable records in the
table and add the records we got from the new request*_
_*please find my comments inline for your suggestions:*_
{color:#4c9aff} Suggestion 1: Reviewing what uniquely identifies rows in
the variable table and ensuring this cannot happen. {color}
{color:#00875a}_my comment: when two users operate on the same variable
at the same time one user updates the variable and other user who has slow
network connection gets the old and new variable info , then it will be not
possible to uniquely identify._{color}
{color:#4c9aff} Suggestion 2: If there are multiple outstanding requests
only processing a single response. {color}
_{color:#00875a}my comment: if we process the single response, then we
may be showing the old information(incase if it is updated at the same time by
the other user operating on the same variable) .{color}_
{color:#4c9aff}Suggestion 3: Consider approaches that would more clearly
show when there is an outstanding request. This would prevent the action from
being taken a second time. If we choose to implement this, we should do so in
its own JIRA and link accordingly.{color}
_{color:#00875a}my comment: yes, it would be to good to prevent the user
from allowing to invoke the action, by creating a mask div and dispaying a
loading status. but this behaviour should be consistent across all the
features. as this is a big change, we need a JIRA.{color}_
{color:#4c9aff} Suggestion 4 : Consider why the Variables response is
taking so long to return. If we choose to investigate here, we should do so in
its own JIRA and link accordingly.{color}
{color:#00875a} _my comment: in case of slow network, we will still have the
same issue (yes, we can try to analyse and optimize the request processing, but
it will still have the problem), so we need to makesure the client handles the
extreme situations._ {color}
> UI - Duplicate Variables
> ------------------------
>
> Key: NIFI-7056
> URL: https://issues.apache.org/jira/browse/NIFI-7056
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI
> Reporter: Matt Gilman
> Assignee: Nagasivanath Dasari
> Priority: Major
>
> When listing variables for a Process Group, the same variable could be listed
> twice. This can happen when the response from the server is very slow and the
> user clicks to see the Variable listing again. We should prevent this
> possibly by:
> - Reviewing what uniquely identifies rows in the variable table and ensuring
> this cannot happen.
> - If there are multiple outstanding requests only processing a single
> response.
> - Consider approaches that would more clearly show when there is an
> outstanding request. This would prevent the action from being taken a second
> time. If we choose to implement this, we should do so in its own JIRA and
> link accordingly.
> - Consider why the Variables response is taking so long to return. If we
> choose to investigate here, we should do so in its own JIRA and link
> accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
