[
https://issues.apache.org/jira/browse/METRON-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16553759#comment-16553759
]
ASF GitHub Bot commented on METRON-1671:
----------------------------------------
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1103
@merrimanr Up front I want to say I agree async is follow-on. I think
polling is fine for right now, but there are potential scaling concerns and I
wanted to get a sense of the reasoning. In practice, it may not actually be
pretty avoidable, but I'm honestly not sure.
For how we'd do it, I'm not super familiar with the the job and status
objects. Having said that, I know a lot of the YARN stuff is already setup in
an relatively async manner, it may simply be a matter of finding the right
hook.
There are a benefit to doing it async, specifically that we could start
having users being able to kick off multiple pcap queries simultaneously
without having their browsers do many requests a second.
I'd also expect similar types of jobs to potentially make their way into
UIs that might also benefit from being async (or even potentially existing
ones) that would benefit from having an async pattern available to model off of.
> Create PCAP UI
> --------------
>
> Key: METRON-1671
> URL: https://issues.apache.org/jira/browse/METRON-1671
> Project: Metron
> Issue Type: Sub-task
> Reporter: Tibor Meller
> Priority: Major
>
> The initial feature set of PCAP UI is the follwing:
> - Filtering by
> - IP Source Address
> - IP Source Port
> - IP Dest Address
> - IP Dest Port
> - Protocol
> - Include Reverse Traffic
> - Free text filtering
> - Showing PDML result
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
