Peer Evaluation for Team Teach

Assignment
Weightage
Grade
Comments

College Board Coverage
20
TBD
TBD

Java Examples
30
TBD
TBD

Popcorn Hack Usage
10
TBD
TBD

Homework
10
TBD
TBD

Grading Plan
10
TBD
TBD

Original an Creative
10
TBD
TBD

Total
90

Assignment
Weightage
Grade (Out of Weightage)
Comments

College Board Coverage
20
17/20
Good coverage of College Board topics, but a few areas could use more depth.

Java Examples
30
25.5/30
Examples are generally solid, but some could be optimized for clarity and efficiency.

Popcorn Hack Usage
10
9.5/10
Excellent integration of Popcorn Hack, demonstrating effective usage of its features.

Homework
10
10/10
All homework completed on time with accurate and thoughtful solutions.

Grading Plan
10
9/10
The grading plan is mostly clear but could benefit from slightly more detail on rubrics.

Original and Creative
10
9.5/10
Creative approach, especially in Java examples and project structure. A standout in this category.

Total
90
90.5/100 (≈ 91%)
Overall great work, just a few areas for improvement in code structure and topic depth.

No evidence will get you a bad grade.  You talked about doing something nice in your blog???

Great summary for each unit, good that you included sample mcqs for each unti

had a good documentation and had a review of all his lessons and he had a peer review which was great and also worked well as seen in his work stuff and included images. very good communication

Neat summary of info to be able to find relevant information along with good explanation of ideation.

Good pressentaiton, good visual representaitons, very engaging

Good organization and notes on lessons for Collegeboard prep. Reviewed Nitin's blog and took inspiration from it. Group chats to show collaboration. Went to office hours to practice which shows dedication.

Nice modals/study guide--> for ap exam.
initiative -->team tech

Made an organized study guide for the AP CSA exam. Demonstrates long term planning. Lots of external communication to work on their team teach.

The way you made your notes like a study guide with practice questions was very nice since it'll help you a lot when the AP exam comes around.

Team Teach Study Guide.   Had takeaways and practice questions.   Peer review of Nitin, he got ideas from the process.  Talked about collaboration plans, slack and office hours.  The had game to make teaching more interesting.

the overview was good and was thorough with all the lessons

The mcq questions are neat. Nice peer review takeaways. And nice self takeways.

Nice organized study guide with practice quesitons.

I like how you talked about improving your work by learning from your group. I also like how you talked about practicing in office hours.

Nice study guide to study for ap exam, good overview overall

Overall, it is solid work and then the blog and the issue are very organized as well. The issue included images and good summaries which will be really helpful when reviewing the units.

Nice summary on the different units and your summary about your lesson was very clear. Also nice study questions within the site.

The page is concise and nicely organized. I like how your explanations for the different units include practice problems and a short description of each unit

Great concise blog. Very organized I like the addition of practice problems to serve as a reminder

I like the conciseness and the explanations for all of the units. I like the summaries.


Upcoming schema changes notification (draft)

I'm drafting this email in public, because why not.
Dear OpenSanctions users,
I'm writing to inform all of you of some planned changes to the OpenSanctions data schema. The outlined changes are additive and - to the best of my understanding - none of them will break existing functions. If you are using OpenSanctions by deploying yente, I would suggest deploying the latest version of the application some time in the next three weeks.

Images
Addresses inline (duplication)
Posts

Thanks for the heads-up, @pudo! ;)


Version bump for Swift 4.1

See #256. Also added support for the new swift_version attribute in the podspec introduced in CocoaPods 1.4.0 (see here).

Merged, thanks for the PR.


"Turn off" does no effect

Steps to reproduce
Clicking "Turn off" in WSA settings does no effect for me.
I click on it, a spinning wheel shows for a quick bit, but then the text on the button does not change. Repeating clicks does nothing as well.
Either it got off and then the status is not reported correctly, or there was some problem during turning off, but the error message was not reported.

✔ Expected Behavior
No effect
(Unrelated: Version of WSA should also be selectable/copyable)
❌ Actual Behavior
Button text should change to "Turn on". There should be a clear status displayed (on or off), and there should be an error message/log if turning off failed for some reason.
Other Software
Windows 11 build 22621.963
Please specify the version of Windows Subsystem for Android
2209.40000.28.0

Hi, are Android apps on your device being terminated? Is the WSA process in task manager unchanged when you click "turn off"?
@jaholme for visibility.

I could not find WSA process at all. Win11 task manager doesn't have process/task filter text box. I checked all processes, did not find anything WSA-related, but I may have missed something.
It can be that WSA settings app can't communicate with WSA service to tell it so switch off because it's already switched off :) so switching off fails. But settings app must be consistent with process state.
If you tell me how to find logs of WSA settings app, I can look them up

If you tell me how to find logs of WSA settings app, I can look them up

Inside the feedback hub is a special record option that'll record what is needed for this issue. Linking that issue here will improve visibility and will increase chances of successfully solving the issue.
From the sounds of things turn off works and the issue is purely cosmetic. Wanting the button to change to turn on when WSA is off.

I'd agree - it's unclear if WSA has been turned off or not.  (It'd also be great if there was a command line flag to turn WSA on/off)

Tracking under feedback hub.


fix the version of the operator image

It should be a minor issue.

You've modified a generated file.
Make the same change here. Then do:
make build-resources

You've modified a generated file.
Make the same change here. Then do:
make build-resources

ahaha

Thanks all and I will fix the yaml file.

Tbh, @zhfeng I need to thank you.. I was struggling since 30 mins because my changes to the operator weren't published ...

@nicolaferraro I met the same issue here :)


Can O' Spam: Watch kieutoc.net

Can O' Spam requests the watch of the watch_keyword kieutoc\.net. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

kieutoc\.net has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


Given a sealed trait, expose all of its case class subtypes's names in ctx in dispatch function

We have a simple use case which is similar to the decode.scala example, https://github.com/propensive/magnolia/blob/master/examples/shared/src/main/scala/decode.scala#L49
We want to decode sth into an instance of a Scala case class, given the type of the root sealed trait of all possible case classes, the root sealed trait also has many other sealed traits who extends it at different levels on the hierarchy.
It seems actually the code in decode.scala is not valid, since actually the subtypes of ctx in dispatch function also contains sealed traits, which are "CallByNeed", so if we do "ctx.subtypes.find(_.typeName.full == name).get" and if the case class that we want to find is actually one of the subtype of a sealed trait which is "CallByNeed" we cannot find the case class since it is not in subtypesArray.
I think it will be beneficial if we can somehow expose the names of all case class subtypes of a root sealed trait so that "ctx.subtypes.find(_.typeName.full == name).get" can be a valid check ?

Just to make sure I understand (additionally, as I don't remember the exact behavior), does ctx.subtypes currently give you the immediate subtypes of the sealed trait (regardless of whether they're traits or case classes), and you would prefer it to give you all the case-class and case-object descendants?
I think that would be desirable, if so! And it shouldn't be too difficult to do.

Just to make sure I understand (additionally, as I don't remember the exact behavior), does ctx.subtypes currently give you the immediate subtypes of the sealed trait (regardless of whether they're traits or case classes), and you would prefer it to give you all the case-class and case-object descendants?
I think that would be desirable, if so! And it shouldn't be too difficult to do.

Hi, thanks for the reply.
It actually gives a mix of sealed traits and case classes of its descendants given a complex type hierarchy, for example, in the following hierarchy, (upper case is sealed trait (A, B, C, D) and lower case is case class(object) (x, e, f, g, h,i), in ctx.subtypes when applying dispatch function on A it may give me an array of [e, f, C, D, x].
                          A
                     /   |  |  \
                   B   C  D   x
                 /  \   |  / \
               e    f  g h  i

I will try to make a simple working example to show the above case later.

Thank you for the explanation!
I'm just wondering about the the subtypes array in your example. Do you know the reason why the array contains e and f (and not B), but also contains C and D while not including g, h or i? Are some of the traits not explicity sealed?

I have created an example to reproduce the issue: https://github.com/gaoxinyang/magnolia-subtypes/tree/master/src/main/scala/com/example/magnolia
run application.scala firstly, you will get a list of subtypes of sealed trait Root: List(org.example.magnolia.A.A1, org.example.magnolia.A.A2, org.example.magnolia.B.CCC1, org.example.magnolia.B.CCC2, org.example.magnolia.C.CC1, org.example.magnolia.C.CC2, org.example.magnolia.C.CC3, org.example.magnolia.C.C1, org.example.magnolia.C.C2, org.example.magnolia.C.C3, org.example.magnolia.B.Root1), which is expected.
Then go to codec.scala, remove the 4 imports from line 38 to line 41, then run application.scala again, you will get subtypes of Root as List(org.example.magnolia.A.A1, org.example.magnolia.A.A2, org.example.magnolia.C.C, org.example.magnolia.B.Root1), in which org.example.magnolia.C.C is a sealed trait

any thoughts ?

@gaoxinyang code from the repo do not compile since 1.16.0. Any chance you could update the example? Maybe I could help with this problem :)
BTW Thanks for making a minimal reproducible example. I wish more people would report issues in that way 🙇


the left- bottom git icon doesn't work well

Issue Type: Bug
When vscode startup ,click the left- bottom git icon,editor will show git branch list on the top,but after about 10s ,it doesn't work.

What do you mean by it doesn't work?

When I click the left- bottom git icon,git branch list doesn't show anymore

Sorry, after waiting a long time ... now everything is fine. Maybe the reason is that there are too many files in my project.


Miscellaneous cleanups

Fix unused-result warnings from gcc-6.3, errors in clean target on cleaning artefacts that don't exist, sort header order.

This looks like good stuff! Thanks!


Allow use of stateful Allocator passed into construtors

Criteo's Vertica integration has noted that our current use of custom allocators is less flexible than ideal:  https://github.com/criteo/vertica-datasketch

Passing allocators to constructors is implemented for Tuple sketch and experimental Theta sketch (located in the "tuple" directory for now) that eventually should replace the current Theta sketch. Feedback is appreciated.

This should now be resolved everywhere.


GEO-TO-HCA tool error - "could not find sra accession"

Description of the task:

The geo-to-hca tool has stopped working for most GSEs this happens for both the spreadsheet downloads on ingest and the command line. When creating a project, you get the below error even when it is not a super-series.

Then when you try to download a spreadsheet in a created project, you get the below error:

I've listed below so examples of GSE having these problems:

GSE205642
GSE156456
GSE202210
GSE195719
GSE202601

Acceptance criteria for the task:

Maybe another instance of: https://app.zenhub.com/workspaces/dcp-ingest-product-development-5f71ca62a3cb47326bdc1b5c/issues/ebi-ait/dcp-ingest-central/805

Amnon to use same fix from SRA.

There seem to be 2 problems here:

GSE156456 - a duplicate of ebi-ait/dcp-ingest-central#805

The following accessions which all give the error:
Error creating spreadsheet for accession GSE202601. Could not find SRA accession; is it a GEO super-series? If yes, please re-try with a sub-series accession

GSE205642
GSE202210
GSE195719
GSE202601

Interesting because in the second list none are superseries and all have data in sra.


Internationalization and localization

Would be nice to support languages other than English. After supporting translatable strings and formatting we can set it up so it's easy for non-technical contributors to add translations to the app.

Any idea on lib you wanna use? I can setup the boilerplate if you wanna use react-intl.

I just started reading i18next docs, is react-intl better?

I dunno. I've only used react-intl. Using react-intl with extract-react-intl-messages is pretty nice. Allows you to define the messages close to where they are used and it makes it pretty easy for non-technical people to add translations.
I'll try and take a look at i18next today or tomorrow.

any of those two is fine imo, would be nice to set up transifex for translations like in Damus


Bug fix for capture size and some python3 compatibility changes

If you want me to split these out, I can.

I think it makes sense to split out into 2 PRs. In terms of Python3 compatibility (which hadn't been a concern, as you can probably tell!) some other files would need to be changed as well

Will do.

split into #85 and #86


fhirserver.ini error

Hi,
i am new to use a fhir server, I need to run my local fhir server for test purpose. I installed mySQL and created a databank. If I'm trying to exectue the commands given in the Installation read-me (using -debug) this error appears:

17:39:38 00:00:00 Databases Loaded
17:39:38 00:00:00 Load Common Terminologies
17:39:38 00:00:00 load ex1 from C:\Program Files\...
17:39:38 00:00:00 Web source from C:\work\fhirserver\web
17:39:38 00:00:00 Initialise endpoint standard at /r3 for r3
17:39:38 00:00:00 EListError: Item not found

(000000000096CC26){FHIRServer.exe} [0000000000D6DC26] Unknown function at TMetho
dImplementationIntercept + $8C8EB6
(000000000022AA52){FHIRServer.exe} [000000000062BA52] Unknown function at TMetho
dImplementationIntercept + $186CE2
(000000000022C900){FHIRServer.exe} [000000000062D900] Unknown function at TMetho
dImplementationIntercept + $188B90
(0000000000049327){FHIRServer.exe} [000000000044A327] Unknown function at __dbk_
fcall_wrapper + $2C2C7
(0000000000049C2B){FHIRServer.exe} [000000000044AC2B] Unknown function at __dbk_
fcall_wrapper + $2CBCB
(0000000000011576){FHIRServer.exe} [0000000000412576]
(00000000000115C1){FHIRServer.exe} [00000000004125C1]
(000000000096CC26){FHIRServer.exe} [0000000000D6DC26] Unknown function at TMetho
dImplementationIntercept + $8C8EB6
(0000000003B5885B){FHIRServer.exe} [0000000003F5985B] Unknown function at TMetho
dImplementationIntercept + $3AB4AEB
(0000000003B55382){FHIRServer.exe} [0000000003F56382] Unknown function at TMetho
dImplementationIntercept + $3AB1612
(0000000003359E91){FHIRServer.exe} [000000000375AE91] Unknown function at TMetho
dImplementationIntercept + $32B6121
(0000000003359B5B){FHIRServer.exe} [000000000375AB5B] Unknown function at TMetho
dImplementationIntercept + $32B5DEB
(000000000335A84F){FHIRServer.exe} [000000000375B84F] Unknown function at TMetho
dImplementationIntercept + $32B6ADF
(0000000003B54360){FHIRServer.exe} [0000000003F55360] Unknown function at TMetho
dImplementationIntercept + $3AB05F0
(0000000003B5FAF0){FHIRServer.exe} [0000000003F60AF0] Unknown function at TMetho
dImplementationIntercept + $3ABBD80
(00000000000149CD){kernel32.dll} [0000000076E859CD] BaseThreadInitThunk + $D
(000000000005283D){ntdll.dll   } [00000000770E383D] RtlUserThreadStart + $1D
17:39:38 00:00:00 Exception in Service Execution:

Item not found
[EListError]

Cheers for your help.

hmm. I just change the ini file around under great time pressure, and won't
get to document it properly until early sept. I'm attaching my copy
Grahame
On Tue, Jul 31, 2018 at 2:01 AM zenkjs<EMAIL_ADDRESS>wrote:

Hi,
i am new to use a fhir server, I need to run my local fhir server for test
purpose. I installed mySQL and created a databank. If I'm trying to exectue
the commands given in the Installation read-me (using -debug) this error
appears:
17:39:38 00:00:00 Databases Loaded
17:39:38 00:00:00 Load Common Terminologies
17:39:38 00:00:00 load ex1 from C:\Program Files...
17:39:38 00:00:00 Web source from C:\work\fhirserver\web
17:39:38 00:00:00 Initialise endpoint standard at /r3 for r3
17:39:38 00:00:00 EListError: Item not found
(000000000096CC26){FHIRServer.exe} [0000000000D6DC26] Unknown function at TMetho
dImplementationIntercept + $8C8EB6
(000000000022AA52){FHIRServer.exe} [000000000062BA52] Unknown function at TMetho
dImplementationIntercept + $186CE2
(000000000022C900){FHIRServer.exe} [000000000062D900] Unknown function at TMetho
dImplementationIntercept + $188B90
(0000000000049327){FHIRServer.exe} [000000000044A327] Unknown function at _dbk
fcall_wrapper + $2C2C7
(0000000000049C2B){FHIRServer.exe} [000000000044AC2B] Unknown function at _dbk
fcall_wrapper + $2CBCB
(0000000000011576){FHIRServer.exe} [0000000000412576]
(00000000000115C1){FHIRServer.exe} [00000000004125C1]
(000000000096CC26){FHIRServer.exe} [0000000000D6DC26] Unknown function at TMetho
dImplementationIntercept + $8C8EB6
(0000000003B5885B){FHIRServer.exe} [0000000003F5985B] Unknown function at TMetho
dImplementationIntercept + $3AB4AEB
(0000000003B55382){FHIRServer.exe} [0000000003F56382] Unknown function at TMetho
dImplementationIntercept + $3AB1612
(0000000003359E91){FHIRServer.exe} [000000000375AE91] Unknown function at TMetho
dImplementationIntercept + $32B6121
(0000000003359B5B){FHIRServer.exe} [000000000375AB5B] Unknown function at TMetho
dImplementationIntercept + $32B5DEB
(000000000335A84F){FHIRServer.exe} [000000000375B84F] Unknown function at TMetho
dImplementationIntercept + $32B6ADF
(0000000003B54360){FHIRServer.exe} [0000000003F55360] Unknown function at TMetho
dImplementationIntercept + $3AB05F0
(0000000003B5FAF0){FHIRServer.exe} [0000000003F60AF0] Unknown function at TMetho
dImplementationIntercept + $3ABBD80
(00000000000149CD){kernel32.dll} [0000000076E859CD] BaseThreadInitThunk + $D
(000000000005283D){ntdll.dll   } [00000000770E383D] RtlUserThreadStart + $1D
17:39:38 00:00:00 Exception in Service Execution:
Item not found
[EListError]
Cheers for your help.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grahamegrieve/fhirserver/issues/93, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AFllFStiueRS7iAOGMwccwgENgvILr2gks5uLy3tgaJpZM4VmsZP
.

--
http://www.healthintersections.com.au /<EMAIL_ADDRESS>/ +61 411 867 065

Somehow I think it's about the version. The version field needs to be filled with just r2 or r3 or r4, right? Not a certain source or whatever?

yes that's right
Grahame
On Fri, Aug 3, 2018 at 10:02 PM zenkjs<EMAIL_ADDRESS>wrote:

Somehow I think it's about the version. The version field needs to be
filled with just r2 or r3 or r4, right? Not a certain source or whatever?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/grahamegrieve/fhirserver/issues/93#issuecomment-410232898,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFllFbSYEEfA9IMSd8V3QZUK96b1Ss-sks5uNDvLgaJpZM4VmsZP
.

--
http://www.healthintersections.com.au /<EMAIL_ADDRESS>/ +61 411 867 065

Closed - a long time ago. Create a new task with more information if there’s still problems


[WIP] Plant release notes for release 0.3.0

TODO

[ ] Release notes for 0.3.0 (this PR)
[ ] Update any links in https://github.com/aeternity/epoch/releases/tag/v0.2.0-good-peers

[ ] Change https://github.com/aeternity/epoch/blob/master/RELEASE-NOTES.md to https://github.com/aeternity/epoch/blob/1be1208c561cfdae856e40ce6bf86ff42b4549ec/RELEASE-NOTES.md

Change https://github.com/aeternity/epoch/blob/master/RELEASE-NOTES.md to https://github.com/aeternity/epoch/blob/1be1208c561cfdae856e40ce6bf86ff42b4549ec/RELEASE-NOTES.md

Using link based on the tag itself sounds better to me e.g. https://github.com/aeternity/epoch/blob/v0.2.0-good-peers/RELEASE-NOTES.md

Using link based on the tag itself sounds better to me e.g. https://github.com/aeternity/epoch/blob/v0.2.0-good-peers/RELEASE-NOTES.md

I need to check whether the doc were updated after the tag.
And actually it is more complex than that as that file refers to master. Let me prepare separate PR for not breaking notes of release 0.2.0.

I see OSX package at https://github.com/aeternity/epoch/releases/download/v0.3.0-big-spenders/epoch-0.3.0-osx-10.12.6.tar.gz
I updated release notes with 5 -> 6 change.


src/collector: Introduce Collector abstraction

The Collector abstraction allows users to provide additional metrics
and their description on each scrape.
See also:

https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#hdr-Custom_Collectors_and_constant_Metrics
https://github.com/prometheus/client_rust/issues/49
https://github.com/prometheus/client_rust/issues/29

I am opening this up as a "Draft" for early feedback.

Also //CC @sd2k

And //CC @08d2

Looks like it will work for the process collector use case! Thanks.

Am I understanding correctly that the user of the lib is expected to reimplement the Collector trait such that calling collect() will do whatever is necessary to produce the metrics, possibly querying some external system?
If so, I think there should be a way to provide an async collector; this will probably require implementing some alternative AsyncRegistry with matching AsyncCollector trait.

Am I understanding correctly that the user of the lib is expected to reimplement the Collector trait such that calling collect() will do whatever is necessary to produce the metrics, possibly querying some external system?
If so, I think there should be a way to provide an async collector; this will probably require implementing some alternative AsyncRegistry with matching AsyncCollector trait.

For context, collect() is called when Prometheus does an HTTP GET of the metrics endpoint for a process. That call is subject to a few layers of (typically sub-second) timeouts and failsafes and is expected to return more or less immediately. An implementation of collect() which blocked in any way that would benefit from async would almost certainly be a design error. If the information returned by collect() needed to come from an external source, then it's I guess a de facto requirement that the retrieval is decoupled from the collecting.

That's what I was thinking, although this example seems to be reading stuff (memory info) from an external system (though, in this case, it's probably unlikely that it should take long).
I have to think a bit more about this; it seems to me that once the collector is added to the registry, there's no easy way to only update it such that it doesn't share state between possibly concurrent calls to the /metrics endpoint, all the while updating said state outside collect().

although this example seems to be reading stuff (memory info) from an external system

callLongGetter? Yeah, it's not obvious to me what that does, exactly... but I wouldn't take too much inspiration from the Java client, which hasn't been updated in a long while, and was never particularly idiomatic. Stick with the Go client, or maybe look at the more active exporters hosted in the Prometheus org.

callLongGetter? Yeah, it's not obvious to me what that does, exactly... but I wouldn't take too much inspiration from the Java client, which hasn't been updated in a long while, and was never particularly idiomatic. Stick with the Go client, or maybe look at the more active exporters hosted in the Prometheus org.

I was thinking more about collectMemoryMetricsLinux. The reason I gave this example was because it's the one mentioned on the docs.

The nature of the problem demands shared state, for sure. (Or a "clever" workaround to avoid it, which, well.) But does shared state imply async, either necessarily or even ideally? I don't think so, but I could be wrong.

I wouldn't say shared state implies async. I think the issue was the way I was thinking about somehow getting the external (non-shared) state as a collector of the shared state, which would have then required collect() to cover async collection.
This could probably be implemented the other way around, with the shared state added as a sub-collector to the non-shared one before returning. Which, if collect() is guaranteed to return quickly, could be called from an async context.

I've been looking a bit more over this, and I think that, basically, a Registry is a Collector: it holds a bunch of metrics, right? That's how the Python client is implemented.
I think that if the lib provided an implementation of Collector for Registry, this would solve the majority of use cases.

Am I understanding correctly that the user of the lib is expected to reimplement the Collector trait such that calling collect() will do whatever is necessary to produce the metrics, possibly querying some external system?

Correct.

If so, I think there should be a way to provide an async collector; this will probably require implementing some alternative AsyncRegistry with matching AsyncCollector trait.

Can you be more concrete? Can you describe a use-case where one would need an async collector?

That call is subject to a few layers of (typically sub-second) timeouts and failsafes, and is expected to return more or less immediately.

Prometheus does not expect the scrape call to return immediately. E.g. from the Prometheus scheduling section:

The default scrape timeout for Prometheus is 10 seconds.

If the information returned by collect() needed to come from an external source, then it's I guess a de facto requirement that the retrieval is decoupled from the collecting.

By default the collection should not be decoupled from the collection. Citing the Prometheus scheduling section:

Metrics should only be pulled from the application when Prometheus scrapes them, exporters should not perform scrapes based on their own timers. That is, all scrapes should be synchronous.

I think that if the lib provided an implementation of Collector for Registry, this would solve the majority of use cases.

Registry could implement Collector, though I have refrained from that thus far to reduce complexity, i.e. not to mix concepts. I expect a user to have a single Registry but many `Collectors.
I don't follow how Registry implementing Collector would solve an issue here. Would you mind expanding on that?

Also note that the encode function take an immutable reference to a Registry, thus two Prometheus servers (e.g. for fault tolerance) may scrape the same endpoint concurrently.

Can you be more concrete? Can you describe a use-case where one would need an async collector?

My use case is exporting metrics that are gathered via multiple HTTP calls. If my HTTP client is async, collect() should be able to handle that.

Prometheus does not expect the scrape call to return immediately. E.g. from the Prometheus scheduling section:

Well, the question is whether collect() itself should return immediately. The other operations could be done outside it, while staying inside the global scrape.

I don't follow how Registry implementing Collector would solve an issue here. Would you mind expanding on that?

See the other point: this is a confusion about whether collect() should be guaranteed to be quick or not and whether a collector should be different from a registry.
If it's not, and random long operations can be done inside collect(), then I can see how a Collector can be different from a Registry, and thus providing an default implementation for Registry doesn't help, since every collector is expected to be different and do its own thing.
However, in the second situation, when the actual gathering of the metrics should be done outside of the collect() method, then basically this becomes generating two separate registries, and combining them before calling collect(). The idea wouldn't be to do the scraping outside of the call from prometheus, but only outside the call to collect().

That example describes how a collector might be "bolted on" to a legacy system. It's not indicative of  best practice. But the point is largely moot, I think.

My current examples why a collector would need to support async are:

collecting metrics from devices via e.g. Bluetooth
collecting container metrics comparable to cadvisor where the list of metrics is basically generated from a current state that is retrieved from the filesystem, containerd APIs etc.

While both approaches could also refresh the data in the background, having it directly connected to the scrape and being able to fetch fresh data on a scrape provides more reliable resolution than scraping previously scraped data.
Now, the data refresh could actually be handled in the http handler, but still it seems like an unnecessary detour.

As a first iteration, I suggest we support synchronous Collector::collect only.

For those that need to call async methods in their Collector::collect call, I suggest you spawn the encode call in a new OS thread (or in a blocking-aware runtime task) and call any async methods via block_on in your Collector::collect implementation.
For those that need concurrency within your Collector::collect implementation (e.g. reaching out to two remote machines concurrently) I suggest you spawn two or more OS threads within your Collector::collect implementation and join the threads again.
For those that need the Collector::collect calls of two distinct Collector implementations to run concurrently, you would be out of luck for now.

In case folks see a large performance hit, e.g. due to thread spawns (even though that should be < 10 microseconds), or (1) and (2) add too much complexity in your Collector::collect implementation or folks need (3) I suggest we design an async Collector::collect as a next step.

@kwiesmueller Thanks for sharing. Let me know in case the threading approach is good enough for you for now, i.e. can collect from the many datasources you are targeting within the Prometheus scrape timeout.
If not, as mentioned above, let's design an async Collector::collect as a next step.

I rebased this pull request onto https://github.com/prometheus/client_rust/pull/100. Everything compiles, tests succeed.
To me the above validates that we should move forward with https://github.com/prometheus/client_rust/pull/100. That said, I do think the signatures in this pull request need more work (e.g. the workaround with MaybeOwned).

Very interested in this work are you looking for help or what would help move this forward.

Very interested in this work

Thanks for the interest. Sorry for the silence.
I rebased this pull request on https://github.com/prometheus/client_rust/pull/105. I want to try out the new API with one of my projects (e.g. https://github.com/mxinden/kademlia-exporter/) before merging #105 and this pull request.

are you looking for help or what would help move this forward.

I would appreciate feedback on #105 and this pull request. You would be of great help by testing this pull request (it is on top of #105) within your application in need of the Collector abstraction @hexfusion.

I have some cycles today will take a look, thanks!

Tested this patch with rust-libp2p and kademlia-exporter. While the Collector trait is still quite verbose (with Cow and MaybeOwned), it does function as expected and allows ad-hoc cheap metric generation.
https://github.com/mxinden/kademlia-exporter/pull/209


Optimization for SEO

@cnunciato this page is already quite well optimized; the main changes are to get the primary focus KW in the metadata ("Azure provider"). "Azure resource group" and "Azure support" are secondary keywords that we are trying to tackle, so if I mislabeled the example by calling it a resource group, hopefully there's a way to fix that while still keeping the keyword.

Proposed changes

Unreleased product version (optional)

Related issues (optional)

PR now being tracked in https://github.com/pulumi/docs/pull/2514. Closing


feat: zipkin traceid response header

Adds http_response_header_for_traceidfor zipkin.
See https://github.com/Kong/kong/pull/9173

Integration Tests [OSS] / integration (kong/kong:master-alpine, false) (pull_request) failing is a known issue

kong/kong:master-alpine image is several weeks out of date. This causes the validation failure for the field we're adding in this branch. I've validated my changes locally against a kong image I've confirmed is up-to-date and contains the field changes we're adding here.


Adding a create item to the list

I still need to finish the tests but I wanted to get a jump on the pull request. This is used when a user would like the ability to add an item as well.
We may want to configure whether it shows up all the time or just when no results are found. My use case requires all the time so that is the way I coded it :-)

Thanks for the PR, but I probably won't take it.
Your use case is quite specific and user interface requirement for adding an item varies a lot.
Someone might ask how do I add description or image.
Adding an item is a bit too much for a simple autocomplete directive.
I'll keep it open for someone who wants this feature.


Disable 1.1 API

@johren @keedya @hohene

I put up a new PR #607 to remove the unit tests that are still using 1.1 apis.

Thanks @johren!  Closing this PR since yours includes these chanages.


feat: Add "Made with Love for FOSS in India" Footer

TLDR;
This feature request proposes integrating a simple footer into the
FOSSTrak application that displays the text "Made with Love for FOSS in India". This
footer will serve as a meaningful acknowledgment of our commitment to the Free and
Open Source Software (FOSS) community in India. The implementation will involve
adding a static footer to the application's user interface, contributing to the project's
 mission of promoting FOSS initiatives within the region.

Thank you for considering this enhancement to the FOSSTrak application!

Feature Description
Add a simple footer to the FOSSTrak application displaying the message "Made with Love for FOSS in India".
Use Case
This footer will serve as a heartfelt acknowledgment of the project's commitment to the Free and Open Source Software (FOSS) community in India.
Proposed Solution
Integrate a static footer at the bottom of the FOSSTrak application's user interface, displaying the text "Made with Love for FOSS in India".
Alternatives Considered
We considered customizing the footer with additional design elements or incorporating regional symbols, but opted for a straightforward text-based approach for simplicity and clarity.
Dependencies
This feature request has minimal dependencies and can be implemented independently of other ongoing developments within the application.
Additional Context
The addition of this footer aligns with our mission to promote FOSS initiatives in India and reinforces our dedication to the local developer community.

Hello,
if no one has taken this issue, I would like to be assigned this issue. Thank you for your swift response.

Eunice

@evnxprk : yes, feel free to pick this up. Assigning the task to you.

Besides the message, is there anything else that you would like to include in the footer?


Support generate hub kubeconfigon on the management cluster for addons

Signed-off-by: zhujian<EMAIL_ADDRESS>If an addon is running in Hosted mode(the addon agent is running on the hosting cluster), we need to generate the hub kubeconfig secret on the hosting cluster.
Hosted mode addon design doc: https://github.com/open-cluster-management-io/enhancements/pull/65

/approve
/lgtm


chore(hbase-phoenix-omid): Update container images ahead of Stackable Release 24.11

Part of #831.

[!TIP]
Please add the scheduled-for/20XX-XX label.

### Update tasks (HBase, Phoenix)
- [ ] Update `versions.py` to reflect the agreed upon versions in the spreadsheet (including the removal of old versions).
- [ ] Upload new versions (see the `hbase/*.sh` scripts).
- [ ] Update `versions.py` to the latest supported version of JVM (base and devel).
- [ ] Update other dependencies if applicable (eg: phoenix, opa_authorizer, etc).
- [ ] Check other operators (getting_started / kuttl) for usage of the versions. Add the PR to the list below.

### Update tasks (Omid)
- [ ] Update `omid/versions.py`to reflect the agreed upon versions in the spreadsheet (including the removal of old versions).
- [ ] Upload new version (see `omid/upload_new_omid_version.sh`).
- [ ] Update `versions.py` to the latest supported version of JVM (base and devel).
- [ ] Update other dependencies if applicable (eg: jmx_exporter, etc).

### Related Pull Requests
- [ ] _Link to the docker-images PR (product update)_
- [ ] _Link to operator PR (getting_started / kuttl)_
- [ ] _Link to any other operator PRs (getting_started / kuttl)_
- [ ] _Link to demo PR (raise against the `next` branch)_

### Acceptance
- [ ] Can build image locally
- [ ] Kuttl smoke tests passes locally
- [ ] Release notes written in a comment below
- [ ] Applicable `release-note` label added to this issue

Testing instructions
# See the latest version at https://pypi.org/project/image-tools-stackabletech/
pip install image-tools-stackabletech==0.0.12

bake --product hbase=x.y.z # where x.y.z is the new version added in this PR
bake --product omid=x.y.z # where x.y.z is the new version added in this PR

kind load docker-image docker.stackable.tech/stackable/hbase:x.y.z-stackable0.0.0-dev
kind load docker-image docker.stackable.tech/stackable/omid:x.y.z-stackable0.0.0-dev

# Change directory into the hbase-operator repository and update the
# product version in tests/test-definition.yaml
./scripts/run-tests --test-suite smoke-latest # or similar
./scripts/run-tests --test omid

Please consider updating this template if these instructions are wrong, or
could be made clearer.

I believe we can bump to Java 17, based on:

7 March, 2022: release 3.8.0 available
Official support for JDK17 (all tests are passing)


Implement Fiori for iOS controls

In Step 4, the ObjectCell class should be FUIObjectTableViewCell

Created pull request #1625

tutorial updated: https://github.com/SAPDocuments/Tutorials/commit/bdafc909ab8e08b404c8926a1fc310fd83a5d6be


Getting kicked from singleplayer loads vanilla multiplayer menu

This only happens if you get kicked in singleplayer, not multiplayer (as shown in video)
I'm using chat spam to get kicked easily with cheats disabled, youll have to get kicked some other way if cheats if enabled
YouTube Video (Using YouTube because the file is too big)

Thanks for reporting this issue, it'll be fixed in the next version


How Do You Get Discovery Working In Docker?

Trying to use the Docker version. Works fine outside of Docker, but it won't discover the hubs. Tried mapping extra ports (docker-compose config), but it won't ever find the hubs.
ports:
  - 61991:61991
  - 61991:61991\udp
  - 5224:5224
  - 5224:5224\udp

I had to add network_mode: host (the equivalent of --net=host on the CLI).
It only worked on Linux... on my Mac (using Docker for Mac), I'd probably have to configure some stuff with the VM.
May be worth adding these notes to the docs?

What made you add the ports listed above and did you keep them after adding host?  I have my docker set for host but it still won't find my hub.


Shader causes my game to crash at random moments

Describe your problem here.
I recently made a shader event that makes a glitchy-noise effect onto GF. But I keep crashing at random moments when the shader is active...
Event Script:
function onEvent(name)
if name == 'Shader-GFChar' then
initLuaShader('GFGlitch')
setSpriteShader('gf', 'GFGlitch')
end
end
function onUpdate()
runHaxeCode([[
game.createRuntimeShader('GFGlitch').setFloat('iTime', ]] .. os.clock() .. [[);
]])
end
Shader Itself:
#pragma header
vec2 uv = openfl_TextureCoordv.xy;
vec2 fragCoord = openfl_TextureCoordv * openfl_TextureSize;
vec2 iResolution = openfl_TextureSize;
uniform float iTime;
#define iChannel0 bitmap
#define texture flixel_texture2D
#define fragColor gl_FragColor
float rand(vec2 co){
return fract(sin(dot(co.xy, vec2(1.9898,78.233))) * 43758.5453);
}
void main(void) {
vec2 uv = fragCoord/iResolution;
vec4 col = texture(iChannel0, uv);
// Add moving glitch effect to RGB channels
float glitchAmount = 0.001;
float speed = 7.0;  // Adjust speed as needed
float timeOffset = iTime * speed;
float glitch = rand(uv + vec2(sin(timeOffset), cos(timeOffset))) * glitchAmount;

col.r = texture(iChannel0, vec2(uv.x + glitch, uv.y)).r;
col.g = texture(iChannel0, vec2(uv.x + glitch * 2.0, uv.y)).g;
col.b = texture(iChannel0, vec2(uv.x + glitch * 3.0, uv.y)).b;

// Add particle-like effects to full opacity pixels
float particleDensity = 0.07;
float particleSize = 0.1;
float particleSpeed = 10.0;
float particleIntensity = 0.5;

float particleOffset = rand(uv) * particleDensity;
float particlePhase = timeOffset * particleSpeed;
float particle = rand(uv + vec2(sin(particlePhase), cos(particlePhase))) * particleIntensity;

// Check if the current pixel has full opacity before applying the particle effect
if (col.a == 1.0) {
    col.rgb += particle * texture(iChannel0, uv + vec2(particleOffset, particleOffset)).rgb;
}

fragColor = col;

}
It may have something to do with high FPS or the fact that I used too much shaders inside my song, but since I've made the event it has been crashing. It's okay with anyone can't help me
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
No, I haven't

Y el codigo tampoco me funcionaba lo edite haci:
function onEvent(name)
if name == 'Shader-GFChar' then
initLuaShader('GFGlitch')
setSpriteShader('gf', 'GFGlitch')
setProperty('gf.useFramePixels', true)
end
end
function onUpdate()
setShaderFloat('gf', 'iTime', os.clock())
end

Turns out that the FPS was the issue, thanks anyway


After upgrade macOS Catalina (10.15.x) to Monterey(12.4)，the youtube-dl 2021.12.17 not work

Checklist

[ ] I'm reporting a broken site support issue
[x] I've verified that I'm running youtube-dl version 2021.12.17
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[ ] I've searched the bugtracker for similar bug reports including closed ones
[ ] I've read bugs section in FAQ

Verbose log

% /usr/local/bin/youtube-dl --version
env: python: No such file or directory

% python3 /usr/local/bin/youtube-dl --version
2021.12.17

% python3 /usr/local/bin/youtube-dl --proxy socks5://<IP_ADDRESS>:1081/ -f 'best[ext=mp4][height<=360]' -o '%(title)s_%(upload_date)s_%(resolution)s.%(ext)s' 'https://www.youtube.com/watch?v=ZggTCJJroyU'
[youtube] ZggTCJJroyU: Downloading webpage
WARNING: Unable to download webpage: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)>
[youtube] ZggTCJJroyU: Downloading API JSON
ERROR: Unable to download API page: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)> (caused by URLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)')))

Description

Recently upgraded the operating system from macOS 10.15.x (ie Catalina) to 12.4 (ie Monterey), before the upgrade, youtube-dl has been working well (version 2021.12.17); but after the upgrade, it can't run……  After adding python3, it can be run, but it cannot be downloaded, and an SSL certificate error is reported.
Help please, thanks.

works fine here:
> youtube-dl -f 'best[ext=mp4][height<=360]' -o '%(title)s_%(upload_date)s_%(resolution)s.%(ext)s' 'https://www.youtube.com/watch?v=ZggTCJJroyU'
[youtube] ZggTCJJroyU: Downloading webpage
[download] Destination: 不愧是天后，王菲翻唱《上海滩》简直好听到炸，开口就被惊艳到
！_20210901_640x360.mp4
[download]   3.2% of 7.92MiB at 65.70KiB/s ETA 01:59

looks like issue is your proxy, or specific to your system.

In #30746 we read that Python isn't installed by default in macOS 12.3+. You should probably explain how your Python was installed, as that could affect how your cert issue occurs.
Also, you should probably install the git master from this repo which is much more current:
python3 -m pip install https://github.com/ytdl-org/youtube-dl/archive/refs/heads/master.tar.gz

(if pip isn't working: https://github.com/ytdl-org/youtube-dl/issues/30788#issuecomment-1107926525).

@dirkf
Thanks，I will try the git master later.
BTW:  I didn't install Python in any way, I just updated the OS from 10.15.x to 12.4, so this Python3 should be built into macOS 12.4. It just doesn't have Python 2.x built in anymore.

Perhaps that's the problem: the old Python3 installation is still there but it doesn't know about the certs in the new system files.
#30746 suggests some ways of installing Python3 on new macOSes.

https://github.com/ytdl-org/youtube-dl/issues/31257

May this https://apple.stackexchange.com/a/446197 be relevant? (tldr; reinstall Homebrew)

https://github.com/ytdl-org/youtube-dl/issues/31258

May this https://apple.stackexchange.com/a/446197 be relevant? (tldr; reinstall Homebrew)

Tried this and no luck

May this https://apple.stackexchange.com/a/446197 be relevant? (tldr; reinstall Homebrew)

Tried reinstalling, no luck

@Cerveus, if you are still having trouble, please open a new issue with the required details.


fixed pagination style bug

Fixed #17  pagination style bug.
And if the Mixin button-color in button componet as a common mixin would be better.

Coverage remained the same at 52.163% when pulling 893adc112336d093a96c6cda88ed41ff81a22d2b on mrxf:master into 32234e45c4ab72768e474bc61ae0161a78e9bc26 on NG-ZORRO:master.

Thanks for your PR, but index.less file is sync with ant design react which should not be changed here.
It seems that class ant-pagination-item-active was added incorrectly when last index or first index is reached
https://github.com/NG-ZORRO/ng-zorro-antd/blob/master/src/components/pagination/nz-pagination.component.ts#L40
Wait for you to PR again, thanks.


RockyLinux.exe -- No networking tools found

Networking appears to be disabled by default and the usual tools (ip, ifupdown, nmcli) are not found.

This installation is as barebones as it gets, to install the tools you refer to, you need to get them using yum. Either way, the setupv2.sh script should get you up and running with net-tools, ncurses, and some other useful packages.
Networking is not disabled as default though, just made a clean installation and no networking issues were found.
Try running setupv2.sh and if you get any issue, I could look further into it.
Also, remember to use WSL 2 as WSL 1 is not supported.

I've confirmed it is running as WSL 2 along with my other WSL distros. When attempting to yum update -y I just see the following. It doesn't ever complete updating the lists from the repositories.

Well, that's weird, just tried in 3 different machines and it ran with no problems whatsoever. All vanilla unmodified WSL2 installations. Maybe a proxy is blocking it? Maybe with a VPN, it shouldn't have a problem tho.
Try running yum clean all and then yum -y update
I'll look further into probable issues, however, I'm not able to reproduce them myself.
Here I'm trying to reproduce the issue on a vanilla WSL2 install.


detect and configure for react externals

Work for this issue will begin begin on branch work-liquid-labs/sdlc-resource-babel-and-rollup/17.


Unify the logging code in SwiftASTContext and improve the readability

Unify the logging code in SwiftASTContext and improve the readability of the logging output.

@swift-ci test and merge


Websocket dependency conflict

After install this package I have this error when creating websocket:
TypeError: ws_1.WebSocketServer is not a constructor

In this code:
 import { WebSocketServer } from 'ws'

 const ws = new WebSocketServer({ port: 9001 })

I see this difference in yarn.lock file:

How can I fix it?

Is this because the version of ws used in this package is older than yours? Can you give me a tiny example to reproduce the issue? Thanks


Sanity checks and minor improvements

A few sanity checks and minor improvements. I was particularly scared by this line:
r_genes, r_tfs, R = np.sort(regnet.index), regnet.columns, np.array(regnet)
since target gene names and regnet rows can easily go out-of-sync (e.g. if regnet rows are not alphabetically sorted for some reason.)
I also turned off use_raw by default, since most of the time it's misleading and things might go unnoticed. It's better to have an explicit option defaulting to False, which is something we also want to do in Scanpy at some point.

@gokceneraslan thank you for the edits! Completely agree with them :+1:
Regarding pSCIRA, the expresison of TFs it is indeed taken into account, if you explore the regulons you will see that TFs are also gene targets:
dorothea_hs = dorothea.load_regulons()
len(set(dorothea_hs.columns) & set(dorothea_hs.index))
> 1395

Another way at looking at this:
np.sum(dorothea_hs.loc[dorothea_hs.columns],axis=0)

tf
ADNP       29.0
ADNP2      31.0
AEBP2      62.0
AHR        11.0
AHRR       -2.0
           ...
ZSCAN5A    13.0
ZSCAN9     61.0
ZXDA       36.0
ZXDB       28.0
ZXDC       46.0
Length: 1395, dtype: float64

The expression of TFs can also affect the activity of other TFs (in a positive/negative manner)

Sorry I wasn't clear enough, I was talking about why this is zero
import dorothea

dorothea_hs = dorothea.load_regulons()
cn = sorted(list(set(dorothea_hs.columns) & set(dorothea_hs.index)))
dorothea_hs.loc[cn, cn].values.diagonal().sum()

For example, I have a FOS high and FOS low clusters but when I run dorothea, I see high FOS activation signal only in FOS low cluster. So I was wondering, if FOS is highly expressed in the first cluster, why doesn't it count as evidence that FOS is active in that cluster too.

In other words, if this is a tf activity prediction method, why is the expression of the tf of interest completely ignored?

Good question! The expression of the TF of interest is ignored because TF activities do not correlate with their expression (high expression does bot mean high activity). Instead, since we use a foot-print methodology, we focus on the targets that are downstream of the TFs. If said TF is truly active, these genes should be more coordinated than the others.


mintter.com is down 500 Internal server error

https://www.mintter.com/

hey @gotjoshua !
thanks for reporting it. we are doing a bunch of changes now to the whole system and that causes the site to go down.
it should be back up now!
thanks again!

Welcome...
But actually why is a "server"needed at all?
Couldn't you deploy an spa via ipfs?


network error accesing session on viewer

I have made a clean install and accesing session in viewer i get "Network error"

I can see all other info on viewer.
Elasticsearch version:
ES Version:                      5.5.2
DB Version:                         51
ES Nodes:                            3/4
Session Indices:                     1
Sessions2:                      62,767 (84,164,217 bytes)
Session Density:                15,691 (21,041,054 bytes)
History Indices:                     1
Histories:                          41 (97,313 bytes)
History Density:                    10 (24,328 bytes)
stats_v3:                            1 (23,488 bytes)
files_v5:                            6 (8,938 bytes)
users_v5:                            1 (5,713 bytes)

Moloch version:
1.5.2-1
OS name and version:
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:        16.04
Codename:       xenial

How was Moloch built/installed: (rpm, deb, easybutton, ...)

Does your viewer.log contain the very end of the log? I ask because I don't see a request to /sessions.json that populates the Sessions page.
What browser (and version) are you using?
Are there any errors in the browser's development console?

Hi,
The sessions page.
Thanks.
Best regards.

It looks like there are no issues with moloch and it is responding as it should. This is likely a network issue. Checkout our FAQ https://github.com/aol/moloch/wiki/FAQ

Hi,
If i access using IE i get:
description": "'Promise' no está definido","number": -2146823279,"stack": "ReferenceError: 'Promise' no está definido
at o.prototype.request (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:6:457083)
at o.prototype[l] (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:6:457405)
at Anonymous function (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:1:372852)
at Anonymous function (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:16:28726)
at C (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:1:148664)
at e.a.getState (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:16:28697)
at e.a.methods.getTableState (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:36:121600)
at e.a.created (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:36:116510)
at xe (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:22:14746)
at l.prototype._init (http://extplxg00003:8005/static/js/app.860227c92262466190db.js:22:30129)" }

Thanks.
Best regards.

We do not support IE: https://github.com/aol/moloch/wiki/FAQ#what-browsers-are-supported

What version of Firefox and Edge have you tried? We only support Firefox 54+ and Edge 14+.

Hi,
Chrome 68.0.3440.106
Firefox 61.0.1
Edge 42.17134.1.0
Thanks.
Best regards.

Are you sure there is nothing in your viewer.log or chrome dev console?  It sounds like viewer is either crashing or not running

Hi,

chrome_debug_log
chrome_debug_har_log
viewer.log
Thanks.
Best regards.

It looks like some of the fields might be missing, try reseting what columns you have displayed maybe.

I have reset to default:

but didn't work

in the viewer.log there is no sessions.json, it seems like the request is either not making it to viewer or viewer is crashing on the request.    Its not in your viewer.log and its not in your test.pcap.
does curl 'http://extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,cert.alt,irc.channel' work?

No, but these works
curl --anyauth 'http://admin:xxxxx@<IP_ADDRESS>:8005/sessions.json'

and
curl --anyauth 'http://admin:xxxxx@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc'

I get "empty reponse" when using fields:
curl --anyauth 'http://admin:xxxxx@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel'
curl: (52) Empty reply from server

viewer.log
Thanks.
Best regards.

Maybe add a -i option
When I try i see the correct output in viewer.log
Tue, 21 Aug 2018 12:54:33 GMT admin GET /sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel 200 670 bytes 78.147 ms

~# curl -vvv -i --anyauth 'http://admin:xxxxx@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&sta
rtTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,em
ail.src,email.dst,email.subject,email.filename,dns.host,irc.channel'
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to extplxg00003.cpd.grupoversia.com (<IP_ADDRESS>) port 8005 (#0)
> GET /sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel HTTP/1.1
> Host: extplxg00003.cpd.grupoversia.com:8005
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< X-Powered-By: Express
X-Powered-By: Express
< WWW-Authenticate: Digest realm="Moloch", nonce="r764oj5Jup4PVR5ETQpD6w1XLAgGRQO2", qop="auth"
WWW-Authenticate: Digest realm="Moloch", nonce="r764oj5Jup4PVR5ETQpD6w1XLAgGRQO2", qop="auth"
< Date: Tue, 21 Aug 2018 14:05:18 GMT
Date: Tue, 21 Aug 2018 14:05:18 GMT
< Connection: keep-alive
Connection: keep-alive
< Transfer-Encoding: chunked
Transfer-Encoding: chunked

<
* Ignoring the response-body
* Connection #0 to host extplxg00003.cpd.grupoversia.com left intact
* Issue another request to this URL: 'http://admin:Versia2017@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel'
* Found bundle for host extplxg00003.cpd.grupoversia.com: 0x7fffd43af760 [can pipeline]
* Re-using existing connection! (#0) with host extplxg00003.cpd.grupoversia.com
* Connected to extplxg00003.cpd.grupoversia.com (<IP_ADDRESS>) port 8005 (#0)
* Server auth using Digest with user 'admin'
> GET /sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel HTTP/1.1
> Host: extplxg00003.cpd.grupoversia.com:8005
> Authorization: Digest username="admin", realm="Moloch", nonce="r764oj5Jup4PVR5ETQpD6w1XLAgGRQO2", uri="/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel", cnonce="NGUzOTE1Y2IyODkxMTlmNmQ2ZjIwMjUxYjI4MWQyNGE=", nc=00000001, qop=auth, response="c03f381a431abd871c0a31cd9df5e1ac"
> User-Agent: curl/7.58.0
> Accept: */*
>
* Connection died, retrying a fresh connect
* Closing connection 0
* Issue another request to this URL: 'http://admin:Versia2017@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel'
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to extplxg00003.cpd.grupoversia.com (<IP_ADDRESS>) port 8005 (#1)
* Server auth using Digest with user 'admin'
> GET /sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel HTTP/1.1
> Host: extplxg00003.cpd.grupoversia.com:8005
> Authorization: Digest username="admin", realm="Moloch", nonce="r764oj5Jup4PVR5ETQpD6w1XLAgGRQO2", uri="/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437&order=srcPort:asc&fields=ipProtocol,firstPacket,srcIp,srcGEO,srcPort,dstIp,dstGEO,dstPort,totPackets,totDataBytes,totBytes,node,http.uri,email.src,email.dst,email.subject,email.filename,dns.host,irc.channel", cnonce="NGUzOTE1Y2IyODkxMTlmNmQ2ZjIwMjUxYjI4MWQyNGE=", nc=00000002, qop=auth, response="065d9ac546ef74d4573394c1eeb207c5"
> User-Agent: curl/7.58.0
> Accept: */*
>

* Empty reply from server
* Connection #1 to host extplxg00003.cpd.grupoversia.com left intact
curl: (52) Empty reply from server

~# curl -vvv -i --anyauth 'http://admin:xxxxx@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437'
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to extplxg00003.cpd.grupoversia.com (<IP_ADDRESS>) port 8005 (#0)
> GET /sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437 HTTP/1.1
> Host: extplxg00003.cpd.grupoversia.com:8005
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
HTTP/1.1 401 Unauthorized
< X-Powered-By: Express
X-Powered-By: Express
< WWW-Authenticate: Digest realm="Moloch", nonce="vPggu7tQixj2geuCez5nRm97yU9ImV5Y", qop="auth"
WWW-Authenticate: Digest realm="Moloch", nonce="vPggu7tQixj2geuCez5nRm97yU9ImV5Y", qop="auth"
< Date: Tue, 21 Aug 2018 14:12:56 GMT
Date: Tue, 21 Aug 2018 14:12:56 GMT
< Connection: keep-alive
Connection: keep-alive
< Transfer-Encoding: chunked
Transfer-Encoding: chunked

<
* Ignoring the response-body
* Connection #0 to host extplxg00003.cpd.grupoversia.com left intact
* Issue another request to this URL: 'http://admin:Versia2017@extplxg00003.cpd.grupoversia.com:8005/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437'
* Found bundle for host extplxg00003.cpd.grupoversia.com: 0x7fffb93630c0 [can pipeline]
* Re-using existing connection! (#0) with host extplxg00003.cpd.grupoversia.com
* Connected to extplxg00003.cpd.grupoversia.com (<IP_ADDRESS>) port 8005 (#0)
* Server auth using Digest with user 'admin'
> GET /sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437 HTTP/1.1
> Host: extplxg00003.cpd.grupoversia.com:8005
> Authorization: Digest username="admin", realm="Moloch", nonce="vPggu7tQixj2geuCez5nRm97yU9ImV5Y", uri="/sessions.json?flatten=1&length=50&facets=1&bounding=last&interval=auto&startTime=1534483837&stopTime=1534487437", cnonce="MjY4ZDFhZWZjODdjMTJmODgxODNlOTljMGYwNDJjNzE=", nc=00000001, qop=auth, response="49f401705ee6b16bdd6b3b1786c70312"
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< X-Powered-By: Express
X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Content-Length: 30554
Content-Length: 30554
< ETag: W/"775a-trBEWHk+VqQevanEO6XSqC7uSPk"
ETag: W/"775a-trBEWHk+VqQevanEO6XSqC7uSPk"
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Date: Tue, 21 Aug 2018 14:12:56 GMT
Date: Tue, 21 Aug 2018 14:12:56 GMT
< Connection: keep-alive
Connection: keep-alive

<
{"recordsTotal":54588289,"recordsFiltered":169245,"graph":{"lpHisto":[[1534483800000,825],[1534483860000,3420],[1534483920000,1795],[1534483980000,2727],[1534484040000,1805],[1534484100000,3776],[1534484160000,1983],[1534484220000,2408],[1534484280000,2299],[1534484340000,2502],[1534484400000,3797],[1534484460000,1999],[1534484520000,2699],[1534484580000,2299],[1534484640000,2810],[1534484700000,2837],[1534484760000,3415],[1534484820000,2178],[1534484880000,2956],[1534484940000,1956],[1534485000000,4068],[1534485060000,1730],[1534485120000,2220],[1534485180000,2912],[1534485240000,2424],[1534485300000,3165],[1534485360000,2122],[1534485420000,2554],[1534485480000,2002],[1534485540000,2552],[1534485600000,2886],[1534485660000,4342],[1534485720000,3830],[1534485780000,3144],[1534485840000,3286],[1534485900000,3626],[1534485960000,3122],[1534486020000,1721],[1534486080000,2817],[1534486140000,2154],[1534486200000,3940],[1534486260000,2959],[1534486320000,2919],[1534486380000,2358],[1534486440000,3329],[1534486500000,2757],[1534486560000,3266],[1534486620000,1983],[1534486680000,3184],[1534486740000,2942],[1534486800000,2517],[1534486860000,5295],[1534486920000,3220],[1534486980000,3001],[1534487040000,2110],[1534487100000,3372],[1534487160000,2353],[1534487220000,2435],[1534487280000,2864],[1534487340000,2846],[1534487400000,2432]],"db1Histo":[[1534483800000,2295216],[1534483860000,4141452],[1534483920000,4761511],[1534483980000,4331769],[1534484040000,3473984],[1534484100000,7450492],[1534484160000,5911899],[1534484220000,3984269],[1534484280000,5423804],[1534484340000,10903529],[1534484400000,4433517],[1534484460000,10200664],[1534484520000,5638864],[1534484580000,2940122],[1534484640000,2747400],[1534484700000,4796777],[1534484760000,5840716],[1534484820000,6416451],[1534484880000,6002649],[1534484940000,3794753],[1534485000000,5627559],[1534485060000,6082740],[1534485120000,8820627],[1534485180000,7371078],[1534485240000,4849965],[1534485300000,4564953],[1534485360000,8524699],[1534485420000,5852909],[1534485480000,4760853],[1534485540000,6287195],[1534485600000,6686877],[1534485660000,8928419],[1534485720000,12455038],[1534485780000,7460637],[1534485840000,7597098],[1534485900000,6658581],[1534485960000,5626372],[1534486020000,3250153],[1534486080000,3427664],[1534486140000,12030531],[1534486200000,7739493],[1534486260000,9426589],[1534486320000,5801704],[1534486380000,5558703],[1534486440000,5662928],[1534486500000,13184187],[1534486560000,7385747],[1534486620000,3400821],[1534486680000,11328690],[1534486740000,5830133],[1534486800000,5461770],[1534486860000,6977174],[1534486920000,24635378],[1534486980000,4773068],[1534487040000,3696095],[1534487100000,5046887],[1534487160000,3655333],[1534487220000,9927302],[1534487280000,9107763],[1534487340000,22179910],[1534487400000,2662890]],"db2Histo":[[1534483800000,7717856],[1534483860000,20794869],[1534483920000,20329922],[1534483980000,22162195],[1534484040000,26632195],[1534484100000,23507068],[1534484160000,28011759],[1534484220000,17424970],[1534484280000,22406040],[1534484340000,26808459],[1534484400000,17687341],[1534484460000,35869572],[1534484520000,18268529],[1534484580000,25691606],[1534484640000,21429572],[1534484700000,20543358],[1534484760000,28058091],[1534484820000,24218744],[1534484880000,26446108],[1534484940000,18561697],[1534485000000,35452339],[1534485060000,23453009],[1534485120000,21229518],[1534485180000,28718035],[1534485240000,22655157],[1534485300000,25751214],[1534485360000,20955183],[1534485420000,22161392],[1534485480000,36808037],[1534485540000,15176767],[1534485600000,22940968],[1534485660000,24321028],[1534485720000,21680566],[1534485780000,22225743],[1534485840000,34271137],[1534485900000,38696010],[1534485960000,29525893],[1534486020000,28449620],[1534486080000,26826159],[1534486140000,26560837],[1534486200000,39563622],[1534486260000,17932401],[1534486320000,30359560],[1534486380000,22246215],[1534486440000,31976207],[1534486500000,37253578],[1534486560000,16363825],[1534486620000,28754237],[1534486680000,23723124],[1534486740000,25104229],[1534486800000,23854319],[1534486860000,26836876],[1534486920000,26486503],[1534486980000,19743858],[1534487040000,30380775],[1534487100000,24952784],[1534487160000,17850341],[1534487220000,38864741],[1534487280000,15431125],[1534487340000,23083263],[1534487400000,17191900]],"pa1Histo":[[1534483800000,10785],[1534483860000,38263],[1534483920000,30540],[1534483980000,29587],[1534484040000,19988],[1534484100000,61738],[1534484160000,49772],[1534484220000,23568],[1534484280000,33851],[1534484340000,42563],[1534484400000,33020],[1534484460000,52565],[1534484520000,42977],[1534484580000,36537],[1534484640000,33630],[1534484700000,23793],[1534484760000,51691],[1534484820000,34175],[1534484880000,37403],[1534484940000,45872],[1534485000000,42823],[1534485060000,31225],[1534485120000,33235],[1534485180000,36892],[1534485240000,45225],[1534485300000,43252],[1534485360000,35889],[1534485420000,44633],[1534485480000,42707],[1534485540000,35961],[1534485600000,39146],[1534485660000,60305],[1534485720000,53317],[1534485780000,40763],[1534485840000,52440],[1534485900000,60334],[1534485960000,38973],[1534486020000,24234],[1534486080000,47718],[1534486140000,59252],[1534486200000,77700],[1534486260000,51590],[1534486320000,37676],[1534486380000,36661],[1534486440000,43022],[1534486500000,88311],[1534486560000,69997],[1534486620000,36233],[1534486680000,46996],[1534486740000,30532],[1534486800000,33901],[1534486860000,59529],[1534486920000,68196],[1534486980000,54299],[1534487040000,51631],[1534487100000,31100],[1534487160000,30338],[1534487220000,160962],[1534487280000,553248],[1534487340000,558330],[1534487400000,345007]],"pa2Histo":[[1534483800000,13532],[1534483860000,50462],[1534483920000,35728],[1534483980000,44476],[1534484040000,41351],[1534484100000,50529],[1534484160000,55624],[1534484220000,33539],[1534484280000,43248],[1534484340000,56073],[1534484400000,34155],[1534484460000,61571],[1534484520000,44312],[1534484580000,47157],[1534484640000,44570],[1534484700000,35429],[1534484760000,63508],[1534484820000,36867],[1534484880000,52358],[1534484940000,43980],[1534485000000,64185],[1534485060000,40833],[1534485120000,33935],[1534485180000,63450],[1534485240000,38944],[1534485300000,53996],[1534485360000,45870],[1534485420000,42122],[1534485480000,72439],[1534485540000,35822],[1534485600000,54028],[1534485660000,53418],[1534485720000,51427],[1534485780000,69584],[1534485840000,69382],[1534485900000,77739],[1534485960000,50529],[1534486020000,44511],[1534486080000,50141],[1534486140000,49365],[1534486200000,69126],[1534486260000,40682],[1534486320000,64899],[1534486380000,44216],[1534486440000,51011],[1534486500000,65200],[1534486560000,33936],[1534486620000,56018],[1534486680000,42891],[1534486740000,47962],[1534486800000,52176],[1534486860000,55707],[1534486920000,89808],[1534486980000,67640],[1534487040000,79880],[1534487100000,53126],[1534487160000,37926],[1534487220000,122386],[1534487280000,285078],[1534487340000,307598],[1534487400000,192159]],"xmin":1534483837000,"xmax":1534487437000,"interval":60},"health":{"cluster_name":"egs-zaingo","status":"green","timed_out":false,"number_of_nodes":4,"number_of_data_nodes":3,"active_primary_shards":2769,"active_shards":5550,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":0,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":100,"version":"5.6.10","molochDbVersion":51,"_timeStamp":1534860776283},"map":{"src":{"ES":22441,"US":1332,"NL":445,"FR":263,"DE":208,"HK":199,"BE":139,"PL":131,"CH":110,"GB":107,"AU":105,"BR":46,"AT":45,"IE":36,"IT":25,"RU":22,"UA":16,"VN":16,"IN":15,"ID":14,"SI":14,"TH":12,"GR":10,"IL":10,"MX":8,"SE":8,"TR":8,"CA":7,"CL":7,"CZ":7,"RS":7,"KR":6,"IR":5,"BA":4,"BD":4,"BG":4,"FI":4,"PT":4,"CO":3,"EG":3,"NG":3,"TZ":3,"AL":2,"AR":2,"DK":2,"JP":2,"KH":2,"MK":2,"MU":2,"NO":2,"PK":2,"RO":2,"TW":2,"ZA":2,"AF":1,"AM":1,"CM":1,"CR":1,"EE":1,"ET":1,"GT":1,"HU":1,"IQ":1,"KG":1,"LV":1,"MT":1,"NZ":1,"PH":1,"SA":1,"SG":1,"SK":1,"TJ":1,"UG":1},"dst":{"ES":8370,"US":6075,"DE":2129,"GB":36,"IE":29,"FR":13,"NL":7,"SI":5,"IL":3,"CU":2,"DK":2,"GR":2,"MX":2,"CA":1,"CH":1,"CZ":1,"FI":1,"TH":1}},"data":[{"srcIp":"<IP_ADDRESS>","firstPacket":1534238389066,"srcDataBytes":2179378,"rootId":"180814-DTWzQflzHFVLx6rnV0iSugtD","dstDataBytes":0,"dstBytes":0,"totDataBytes":2179378,"srcPort":21858,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534484213981,"dstPort":514,"totBytes":2259378,"dstIp":"<IP_ADDRESS>","srcBytes":2259378,"index":"sessions2-180817","id":"180817-DTXfZEaf17xC05lzlHuy2G8Y"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238389066,"srcDataBytes":2173434,"rootId":"180814-DTWzQflzHFVLx6rnV0iSugtD","dstDataBytes":0,"dstBytes":0,"totDataBytes":2173434,"srcPort":21858,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534485411103,"dstPort":514,"totBytes":2253434,"dstIp":"<IP_ADDRESS>","srcBytes":2253434,"index":"sessions2-180817","id":"180817-DTWFVFsPaitC4p3yy2cWbHcV"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238389066,"srcDataBytes":2183030,"rootId":"180814-DTWzQflzHFVLx6rnV0iSugtD","dstDataBytes":0,"dstBytes":0,"totDataBytes":2183030,"srcPort":21858,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486550086,"dstPort":514,"totBytes":2263030,"dstIp":"<IP_ADDRESS>","srcBytes":2263030,"index":"sessions2-180817","id":"180817-DTXAJrwD_ctF7oxMK0xLgNqm"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238390054,"srcDataBytes":2226213,"rootId":"180814-DTV92rTUpNdFmZJir5x4ORXZ","dstDataBytes":0,"dstBytes":0,"totDataBytes":2226213,"srcPort":45628,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486168621,"dstPort":514,"totBytes":2306213,"dstIp":"<IP_ADDRESS>","srcBytes":2306213,"index":"sessions2-180817","id":"180817-DTX2G3hEicdOaaMwEhZKuaYn"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238393950,"srcDataBytes":520000,"rootId":"180815-DTV-sJ1wbGZICoJekHcNAsrD","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486230995,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTUVsXNT_SVIi4n1geLaICNu"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238393965,"srcDataBytes":520000,"rootId":"180814-DTWwfNKOwc5IhIkEB2Tp2e-w","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486608803,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTXZd-_Bk0xJF6u-MnT52WXH"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238393981,"srcDataBytes":520000,"rootId":"180814-DTWFCtLu3m9LtZvrX34P6TuF","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486571587,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTXFCT0zHWdI6qUj4hI78nnD"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238393996,"srcDataBytes":520000,"rootId":"180814-DTU-MjV26JhHra3E5htZrd7b","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486540711,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTVcztPypo9OprKHnE0lF6Ao"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238394011,"srcDataBytes":520000,"rootId":"180815-DTV0pQVvn2lEqIcslKZdFbUc","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486231061,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTWLQa0NPqNDxaZjliisou4r"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238394026,"srcDataBytes":520000,"rootId":"180815-DTX2yp2VhYJNoIgOMAr6HCbe","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486231077,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTXY5396yAtNGa5cTBs9ezov"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238394040,"srcDataBytes":520000,"rootId":"180815-DTUI5pmZsxpKooAM2vzPoXTf","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486231094,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTU9r1uZ3OBEf4QgQq0154Fb"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238394055,"srcDataBytes":520000,"rootId":"180814-DTUVIb6XFulAq7xhATtnsqvv","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486559292,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTUOEvhn8gZN0oE_bF2TNWLI"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238394070,"srcDataBytes":520000,"rootId":"180814-DTWTA4hBaMtExIi1lgQPGGj2","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486571673,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTUTGX6fGtpHbagICnM6LEe4"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238394084,"srcDataBytes":520000,"rootId":"180814-DTU_MllZJsxJDJVCBejHhz-w","dstDataBytes":0,"dstBytes":0,"totDataBytes":520000,"srcPort":49414,"totPackets":10000,"ipProtocol":17,"srcPackets":10000,"node":"EXTPLXG00003","dstPackets":0,"lastPacket":1534486559320,"dstPort":3071,"totBytes":600000,"dstIp":"<IP_ADDRESS>","srcBytes":600000,"index":"sessions2-180817","id":"180817-DTXyjZSdeo5LEb32rEEc_y8J"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238405748,"srcDataBytes":0,"rootId":"180817-DTWFCNt7H6dHmr6yNDdUopmm","dstDataBytes":0,"dstBytes":2270225,"totDataBytes":0,"srcPort":2407,"totPackets":10000,"ipProtocol":6,"srcPackets":4643,"node":"EXTPLXG00003","dstPackets":5357,"lastPacket":1534485501331,"dstPort":993,"totBytes":2750874,"dstIp":"<IP_ADDRESS>","srcGEO":"NL","srcBytes":480649,"index":"sessions2-180817","id":"180817-DTWFCNt7H6dHmr6yNDdUopmm"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238439027,"srcDataBytes":0,"rootId":"180816-DTWidR-TGbBK75m8xKxk8uj5","dstDataBytes":0,"dstBytes":2955728,"totDataBytes":0,"srcPort":20011,"totPackets":10000,"ipProtocol":6,"srcPackets":5062,"node":"EXTPLXG00003","dstPackets":4938,"lastPacket":1534484570326,"dstPort":993,"totBytes":3396747,"dstIp":"<IP_ADDRESS>","srcGEO":"NL","srcBytes":441019,"index":"sessions2-180817","id":"180817-DTX-npto0thCwJvstnn68pOX"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534238846684,"srcDataBytes":0,"rootId":"180815-DTXqlhG4vKBMg73eJ6B2f3I5","dstDataBytes":0,"dstBytes":2159409,"totDataBytes":0,"srcPort":54782,"totPackets":10000,"ipProtocol":6,"srcPackets":4780,"node":"EXTPLXG00003","dstPackets":5220,"lastPacket":1534484978343,"dstPort":993,"totBytes":2787285,"dstIp":"<IP_ADDRESS>","srcGEO":"NL","srcBytes":627876,"index":"sessions2-180817","id":"180817-DTVjJvUFPYZG1p2M8NNoicmY"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534283687650,"srcDataBytes":0,"rootId":"180815-DTW4Fu5YxHtHS5M9nRe6J6SK","dstDataBytes":0,"dstBytes":490098,"totDataBytes":0,"srcPort":0,"totPackets":10000,"ipProtocol":1,"srcPackets":4999,"node":"EXTPLXG00003","dstPackets":5001,"lastPacket":1534484772692,"dstPort":0,"totBytes":980000,"dstIp":"<IP_ADDRESS>","srcBytes":489902,"index":"sessions2-180817","id":"180817-DTUeHJC2rQ5JboGo9MSKfq7x"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534370519384,"srcDataBytes":0,"rootId":"180817-DTWtQhd9xTpLXZZuERkmioMS","dstDataBytes":0,"dstBytes":2008608,"totDataBytes":0,"srcPort":59857,"totPackets":10000,"ipProtocol":6,"srcPackets":5295,"node":"EXTPLXG00003","dstPackets":4705,"lastPacket":1534484523652,"dstPort":993,"totBytes":2470635,"dstIp":"<IP_ADDRESS>","srcGEO":"NL","srcBytes":462027,"index":"sessions2-180817","id":"180817-DTWtQhd9xTpLXZZuERkmioMS"},{"srcIp":"<IP_ADDRESS>","dstGEO":"DE","firstPacket":1534406475759,"srcDataBytes":0,"rootId":"180816-DTVoySF6ztBJQ43o5uqYXfFW","dstDataBytes":0,"dstBytes":1742,"totDataBytes":0,"srcPort":52695,"totPackets":65,"ipProtocol":6,"srcPackets":39,"node":"EXTPLXG00003","dstPackets":26,"lastPacket":1534485038417,"dstPort":443,"totBytes":4498,"dstIp":"<IP_ADDRESS>","srcBytes":2756,"index":"sessions2-180817","id":"180817-DTWMzfeSaHBIVbOUIUGRMXzA"},{"srcIp":"<IP_ADDRESS>","dstGEO":"DE","firstPacket":1534406475759,"srcDataBytes":0,"rootId":"180816-DTVoySF6ztBJQ43o5uqYXfFW","dstDataBytes":0,"dstBytes":16900,"totDataBytes":0,"srcPort":52695,"totPackets":132,"ipProtocol":6,"srcPackets":75,"node":"EXTPLXG00003","dstPackets":57,"lastPacket":1534485777820,"dstPort":443,"totBytes":32950,"dstIp":"<IP_ADDRESS>","srcBytes":16050,"index":"sessions2-180817","id":"180817-DTVplpStFDFIgJ30JUGGW8fG"},{"srcIp":"<IP_ADDRESS>","dstGEO":"DE","firstPacket":1534406475759,"srcDataBytes":0,"rootId":"180816-DTVoySF6ztBJQ43o5uqYXfFW","dstDataBytes":0,"dstBytes":6892,"totDataBytes":0,"srcPort":52695,"totPackets":103,"ipProtocol":6,"srcPackets":60,"node":"EXTPLXG00003","dstPackets":43,"lastPacket":1534486497821,"dstPort":443,"totBytes":13172,"dstIp":"<IP_ADDRESS>","srcBytes":6280,"index":"sessions2-180817","id":"180817-DTXUfGvOlNVJwKNFHC4jrmps"},{"srcIp":"<IP_ADDRESS>","dstGEO":"DE","firstPacket":1534406475759,"srcDataBytes":0,"rootId":"180816-DTVoySF6ztBJQ43o5uqYXfFW","dstDataBytes":0,"dstBytes":1854,"totDataBytes":0,"srcPort":52695,"totPackets":67,"ipProtocol":6,"srcPackets":40,"node":"EXTPLXG00003","dstPackets":27,"lastPacket":1534484322994,"dstPort":443,"totBytes":4751,"dstIp":"<IP_ADDRESS>","srcBytes":2897,"index":"sessions2-180817","id":"180817-DTWAszb86ghN259YNUugozO7"},{"srcIp":"<IP_ADDRESS>","dstGEO":"DE","firstPacket":1534406475759,"srcDataBytes":0,"rootId":"180816-DTVoySF6ztBJQ43o5uqYXfFW","dstDataBytes":0,"dstBytes":7936,"totDataBytes":0,"srcPort":52695,"totPackets":103,"ipProtocol":6,"srcPackets":58,"node":"EXTPLXG00003","dstPackets":45,"lastPacket":1534487195320,"dstPort":443,"totBytes":14584,"dstIp":"<IP_ADDRESS>","srcBytes":6648,"index":"sessions2-180817","id":"180817-DTUxzTQA1i9LCqq72dDcbADo"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534416481774,"srcDataBytes":0,"rootId":"180816-DTX6qL8fD8xNj7Vi1vB9wJVB","dstDataBytes":0,"dstBytes":4500,"totDataBytes":0,"srcPort":56538,"totPackets":112,"ipProtocol":6,"srcPackets":70,"node":"EXTPLXG00003","dstPackets":42,"lastPacket":1534487124174,"dstPort":993,"totBytes":10467,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5967,"index":"sessions2-180817","id":"180817-DTVZucAc4BBCfItYBZgP5nwr"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534416481774,"srcDataBytes":0,"rootId":"180816-DTX6qL8fD8xNj7Vi1vB9wJVB","dstDataBytes":0,"dstBytes":4086,"totDataBytes":0,"srcPort":56538,"totPackets":104,"ipProtocol":6,"srcPackets":65,"node":"EXTPLXG00003","dstPackets":39,"lastPacket":1534484232630,"dstPort":993,"totBytes":9586,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5500,"index":"sessions2-180817","id":"180817-DTXiG4NXOCVNe5G6zyEx2l3N"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534416481774,"srcDataBytes":0,"rootId":"180816-DTX6qL8fD8xNj7Vi1vB9wJVB","dstDataBytes":0,"dstBytes":3864,"totDataBytes":0,"srcPort":56538,"totPackets":100,"ipProtocol":6,"srcPackets":63,"node":"EXTPLXG00003","dstPackets":37,"lastPacket":1534486374798,"dstPort":993,"totBytes":9154,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5290,"index":"sessions2-180817","id":"180817-DTUhSZmIYjpIaK8nXZrf6Fgt"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534416481774,"srcDataBytes":0,"rootId":"180816-DTX6qL8fD8xNj7Vi1vB9wJVB","dstDataBytes":0,"dstBytes":4556,"totDataBytes":0,"srcPort":56538,"totPackets":109,"ipProtocol":6,"srcPackets":67,"node":"EXTPLXG00003","dstPackets":42,"lastPacket":1534484946198,"dstPort":993,"totBytes":10325,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5769,"index":"sessions2-180817","id":"180817-DTUPn_GzvJ9N3Yk5S_eKid4P"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534416481774,"srcDataBytes":0,"rootId":"180816-DTX6qL8fD8xNj7Vi1vB9wJVB","dstDataBytes":0,"dstBytes":4152,"totDataBytes":0,"srcPort":56538,"totPackets":108,"ipProtocol":6,"srcPackets":68,"node":"EXTPLXG00003","dstPackets":40,"lastPacket":1534485682274,"dstPort":993,"totBytes":9850,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5698,"index":"sessions2-180817","id":"180817-DTUB-Br6F8hKhKhSoG3Ynbr8"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534417121768,"srcDataBytes":0,"rootId":"180816-DTUBEaEYbFJMHqCYliR4PDC7","dstDataBytes":0,"dstBytes":1444,"totDataBytes":0,"srcPort":48664,"totPackets":8,"ipProtocol":6,"srcPackets":4,"node":"EXTPLXG00003","dstPackets":4,"lastPacket":1534483900450,"dstPort":443,"totBytes":3412,"dstIp":"<IP_ADDRESS>","srcBytes":1968,"index":"sessions2-180817","id":"180817-DTXlH_CFamxGY7k5vlO2_HZV"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534417121768,"srcDataBytes":0,"rootId":"180816-DTUBEaEYbFJMHqCYliR4PDC7","dstDataBytes":0,"dstBytes":1444,"totDataBytes":0,"srcPort":48664,"totPackets":8,"ipProtocol":6,"srcPackets":4,"node":"EXTPLXG00003","dstPackets":4,"lastPacket":1534485400473,"dstPort":443,"totBytes":3412,"dstIp":"<IP_ADDRESS>","srcBytes":1968,"index":"sessions2-180817","id":"180817-DTVp4q9f_hVBWalcJ-tS9-k7"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534417121768,"srcDataBytes":0,"rootId":"180816-DTUBEaEYbFJMHqCYliR4PDC7","dstDataBytes":0,"dstBytes":2166,"totDataBytes":0,"srcPort":48664,"totPackets":12,"ipProtocol":6,"srcPackets":6,"node":"EXTPLXG00003","dstPackets":6,"lastPacket":1534484800463,"dstPort":443,"totBytes":5118,"dstIp":"<IP_ADDRESS>","srcBytes":2952,"index":"sessions2-180817","id":"180817-DTVBn0aeoVtDJLAf8q6mFvdf"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534417121768,"srcDataBytes":0,"rootId":"180816-DTUBEaEYbFJMHqCYliR4PDC7","dstDataBytes":0,"dstBytes":1444,"totDataBytes":0,"srcPort":48664,"totPackets":8,"ipProtocol":6,"srcPackets":4,"node":"EXTPLXG00003","dstPackets":4,"lastPacket":1534486900497,"dstPort":443,"totBytes":3412,"dstIp":"<IP_ADDRESS>","srcBytes":1968,"index":"sessions2-180817","id":"180817-DTUQqyP1cHNNT5bQopbejjQ9"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534417121768,"srcDataBytes":0,"rootId":"180816-DTUBEaEYbFJMHqCYliR4PDC7","dstDataBytes":0,"dstBytes":2166,"totDataBytes":0,"srcPort":48664,"totPackets":12,"ipProtocol":6,"srcPackets":6,"node":"EXTPLXG00003","dstPackets":6,"lastPacket":1534486300488,"dstPort":443,"totBytes":5118,"dstIp":"<IP_ADDRESS>","srcBytes":2952,"index":"sessions2-180817","id":"180817-DTU-K1VHVGdPrq-TuzdfPaVK"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534421971417,"srcDataBytes":0,"rootId":"180816-DTVR9cjTP7JGEJ59eyVN16MU","dstDataBytes":0,"dstBytes":2120,"totDataBytes":0,"srcPort":63843,"totPackets":31,"ipProtocol":6,"srcPackets":20,"node":"EXTPLXG00003","dstPackets":11,"lastPacket":1534485281544,"dstPort":993,"totBytes":3940,"dstIp":"<IP_ADDRESS>","srcGEO":"ES","srcBytes":1820,"index":"sessions2-180817","id":"180817-DTUPtXoO1adBJq2iZ0EfWNK2"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534421971417,"srcDataBytes":0,"rootId":"180816-DTVR9cjTP7JGEJ59eyVN16MU","dstDataBytes":0,"dstBytes":3081,"totDataBytes":0,"srcPort":63843,"totPackets":45,"ipProtocol":6,"srcPackets":30,"node":"EXTPLXG00003","dstPackets":15,"lastPacket":1534486768492,"dstPort":993,"totBytes":5811,"dstIp":"<IP_ADDRESS>","srcGEO":"ES","srcBytes":2730,"index":"sessions2-180817","id":"180817-DTWfHSg7XxZIDLZH15duQPPY"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534421971417,"srcDataBytes":0,"rootId":"180816-DTVR9cjTP7JGEJ59eyVN16MU","dstDataBytes":0,"dstBytes":2054,"totDataBytes":0,"srcPort":63843,"totPackets":30,"ipProtocol":6,"srcPackets":20,"node":"EXTPLXG00003","dstPackets":10,"lastPacket":1534485884305,"dstPort":993,"totBytes":3874,"dstIp":"<IP_ADDRESS>","srcGEO":"ES","srcBytes":1820,"index":"sessions2-180817","id":"180817-DTUY1C5MNjNGiqcpK_GtCEhO"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534421971417,"srcDataBytes":0,"rootId":"180816-DTVR9cjTP7JGEJ59eyVN16MU","dstDataBytes":0,"dstBytes":2120,"totDataBytes":0,"srcPort":63843,"totPackets":31,"ipProtocol":6,"srcPackets":20,"node":"EXTPLXG00003","dstPackets":11,"lastPacket":1534487365820,"dstPort":993,"totBytes":3940,"dstIp":"<IP_ADDRESS>","srcGEO":"ES","srcBytes":1820,"index":"sessions2-180817","id":"180817-DTV85zLmk9FCC4QTFapPtFPy"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534421971417,"srcDataBytes":0,"rootId":"180816-DTVR9cjTP7JGEJ59eyVN16MU","dstDataBytes":0,"dstBytes":3081,"totDataBytes":0,"srcPort":63843,"totPackets":45,"ipProtocol":6,"srcPackets":30,"node":"EXTPLXG00003","dstPackets":15,"lastPacket":1534484683396,"dstPort":993,"totBytes":5811,"dstIp":"<IP_ADDRESS>","srcGEO":"ES","srcBytes":2730,"index":"sessions2-180817","id":"180817-DTUtYmH4UhxHLbtj2A6_ElJy"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534423332412,"srcDataBytes":0,"rootId":"180816-DTVnQALgr7FO_bMMsEzrJ8oC","dstDataBytes":0,"dstBytes":4158,"totDataBytes":0,"srcPort":59541,"totPackets":106,"ipProtocol":6,"srcPackets":66,"node":"EXTPLXG00003","dstPackets":40,"lastPacket":1534483892201,"dstPort":993,"totBytes":9864,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5706,"index":"sessions2-180817","id":"180817-DTWOnyqfKX5LnpJvIn2OVrVy"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534423332412,"srcDataBytes":0,"rootId":"180816-DTVnQALgr7FO_bMMsEzrJ8oC","dstDataBytes":0,"dstBytes":182964,"totDataBytes":0,"srcPort":59541,"totPackets":288,"ipProtocol":6,"srcPackets":126,"node":"EXTPLXG00003","dstPackets":162,"lastPacket":1534484606748,"dstPort":993,"totBytes":193104,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":10140,"index":"sessions2-180817","id":"180817-DTX75kaoIhxEWKkKAblatPAx"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534423332412,"srcDataBytes":0,"rootId":"180816-DTVnQALgr7FO_bMMsEzrJ8oC","dstDataBytes":0,"dstBytes":4485,"totDataBytes":0,"srcPort":59541,"totPackets":108,"ipProtocol":6,"srcPackets":66,"node":"EXTPLXG00003","dstPackets":42,"lastPacket":1534486772142,"dstPort":993,"totBytes":10191,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5706,"index":"sessions2-180817","id":"180817-DTUC22WHGXVNTbRPHwpd1Kzi"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534423332412,"srcDataBytes":0,"rootId":"180816-DTVnQALgr7FO_bMMsEzrJ8oC","dstDataBytes":0,"dstBytes":4142,"totDataBytes":0,"srcPort":59541,"totPackets":106,"ipProtocol":6,"srcPackets":66,"node":"EXTPLXG00003","dstPackets":40,"lastPacket":1534486033910,"dstPort":993,"totBytes":9710,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5568,"index":"sessions2-180817","id":"180817-DTVJgtbvi3lAH6_APeJaQdcg"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534423332412,"srcDataBytes":0,"rootId":"180816-DTVnQALgr7FO_bMMsEzrJ8oC","dstDataBytes":0,"dstBytes":3944,"totDataBytes":0,"srcPort":59541,"totPackets":102,"ipProtocol":6,"srcPackets":65,"node":"EXTPLXG00003","dstPackets":37,"lastPacket":1534485299359,"dstPort":993,"totBytes":9446,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5502,"index":"sessions2-180817","id":"180817-DTXxuE-oq4RKYou_UppAJI_E"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534432018650,"srcDataBytes":0,"rootId":"180816-DTWJZvhqar9C26vvDVQq69Tr","dstDataBytes":0,"dstBytes":4272,"totDataBytes":0,"srcPort":48369,"totPackets":106,"ipProtocol":6,"srcPackets":66,"node":"EXTPLXG00003","dstPackets":40,"lastPacket":1534484650526,"dstPort":993,"totBytes":9897,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5625,"index":"sessions2-180817","id":"180817-DTXN3tJNp-dNqYzQb19NMNb6"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534432018650,"srcDataBytes":0,"rootId":"180816-DTWJZvhqar9C26vvDVQq69Tr","dstDataBytes":0,"dstBytes":3926,"totDataBytes":0,"srcPort":48369,"totPackets":98,"ipProtocol":6,"srcPackets":60,"node":"EXTPLXG00003","dstPackets":38,"lastPacket":1534486081708,"dstPort":993,"totBytes":9018,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5092,"index":"sessions2-180817","id":"180817-DTW9EfmVdi1OpacUdBQEHyFH"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534432018650,"srcDataBytes":0,"rootId":"180816-DTWJZvhqar9C26vvDVQq69Tr","dstDataBytes":0,"dstBytes":4082,"totDataBytes":0,"srcPort":48369,"totPackets":106,"ipProtocol":6,"srcPackets":67,"node":"EXTPLXG00003","dstPackets":39,"lastPacket":1534485349670,"dstPort":993,"totBytes":9714,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5632,"index":"sessions2-180817","id":"180817-DTW2Ko2Gx59N7ZIQoPpO_Y80"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534432018650,"srcDataBytes":0,"rootId":"180816-DTWJZvhqar9C26vvDVQq69Tr","dstDataBytes":0,"dstBytes":4082,"totDataBytes":0,"srcPort":48369,"totPackets":102,"ipProtocol":6,"srcPackets":63,"node":"EXTPLXG00003","dstPackets":39,"lastPacket":1534483894960,"dstPort":993,"totBytes":9450,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5368,"index":"sessions2-180817","id":"180817-DTUu68CUv-ZASIW9eItHOAEd"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534432018650,"srcDataBytes":0,"rootId":"180816-DTWJZvhqar9C26vvDVQq69Tr","dstDataBytes":0,"dstBytes":4428,"totDataBytes":0,"srcPort":48369,"totPackets":110,"ipProtocol":6,"srcPackets":69,"node":"EXTPLXG00003","dstPackets":41,"lastPacket":1534486781626,"dstPort":993,"totBytes":10329,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5901,"index":"sessions2-180817","id":"180817-DTWTS7BA3qVE_rFc9TSjoonO"},{"srcIp":"<IP_ADDRESS>","firstPacket":1534432044706,"srcDataBytes":0,"rootId":"180816-DTVtjlhIUNpNw7* Connection #0 to host extplxg00003.cpd.grupoversia.com left intact
ZzFDTIzK83","dstDataBytes":0,"dstBytes":4482,"totDataBytes":0,"srcPort":52361,"totPackets":108,"ipProtocol":6,"srcPackets":66,"node":"EXTPLXG00003","dstPackets":42,"lastPacket":1534485391461,"dstPort":993,"totBytes":10185,"dstIp":"<IP_ADDRESS>","srcGEO":"US","srcBytes":5703,"index":"sessions2-180817","id":"180817-DTUfdkohUhNJsoswGRcleRGR"}]}

Don't care about password, is a temporal one, but thanks for pointing !!!
The viewer is running for a week:
# systemctl status molochviewer
● molochviewer.service - Moloch Viewer
   Loaded: loaded (/usr/lib/systemd/system/molochviewer.service; enabled; vendor preset: enabled)
   Active: active (running) since lun 2018-08-13 08:01:55 CEST; 1 weeks 1 days ago
 Main PID: 4623 (sh)
    Tasks: 11
   Memory: 102.2M
      CPU: 3min 25.692s
   CGroup: /system.slice/molochviewer.service
           ├─4623 /bin/sh -c /data/moloch/bin/node viewer.js -c /data/moloch/etc/config.ini --debug >> /data/moloch/logs/viewer.log 2>&1
           └─4624 /data/moloch/bin/node viewer.js -c /data/moloch/etc/config.ini --debug

ago 13 08:01:55 EXTPLXG00003 systemd[1]: Started Moloch Viewer.

I think i have the latest version:
# dpkg -l|grep -i moloch
ii  moloch                               1.5.2-1                                    amd64        Moloch Full Packet System

This is a fresh install, before we had 0.19 from ubuntu repo running on the same host with no issues.
Thanks.
Best regards.

ya i have no clue, sorry.  Also the tcpdump you did previously showed that sessions.json wasn't being sent.  You might try that again with sessions.json and double check that tcpdump doesn't show the packets being sent.  Do you have selinux or any thing else on the network that might be closing/preventing the connection?  Have you tried using localhost:8005 and running on same machine?

I have tested curl from localhost and from other vm on the same net and works fine, will keep up investigating on network issues.
Thanks.
Best regards.

Oh so viewer works normally on localhost and other vms, but just on this 1 machine it has issues?

I have made an ssh tunnel to the moloch host and accesing local 8005 port works fine

Ok then i think we can close this issue.  I didn't understand that it worked locally, and doesn't work remotely.  That really is a network/firewall/listening address issue

OK, closing.
Thanks for your time and kind support.


doc typo on progress

Hello : progress contains pagination component here : http://vuikit.github.io/vuikit/#!/progress
The vk-progress component renders a progress bar.
PROPS
SLOTS
EXAMPLE
<vk-pagination :progress="100"
color="warning"
stripe>
40%

Thanks, but can you be more specific?

isn't there a typo as it should be called vk-progress and not vk-pagination ?

Ah, true! Fixed in dev but anyway, VkProgress has been deprecated in vuikit next as any other component that was acting as just UIkit alternative syntax.


Add callback func for thermostat target

Following on from #29, here's some code to expose changes to the thermostat target temperature in the same manner as the switch.

Looks good.
But it's better to define a method in the Thermostat interface under hc/model/thermostat.go. Then implement the method in thermostat struct and change the field name from OnTargetTempChange func(float64) to onTargetTempChange func(float64) to make it private.

Of course, yes. My Go is a bit rusty. Have another look at the latest commit.

Nice 👍

Thanks!


Spelling pkg dev compiler

This change is scoped to pkg/dev_compiler with any files that happened to be changed in those commits per https://github.com/dart-lang/sdk/issues/50754, it's <70 files.
It's getting a bit hard for me to tease out pieces, but this should be pretty reviewable.

CL: https://dart-review.googlesource.com/c/sdk/+/277743

There are conflicts, please resolve them.

Apparently, the conflicts on this PR can't be resolved in the GitHub UI. Please fix (note: pkg/js/proposal.md has been deleted, so just remove those changes and it should merge).


Perfect Vision's limited sight radius not respected

Need to check whether PV has limited sight radius set and make sure the vision testing adapts accordingly. Related: #4

Fixed in v0.4.0


Add base Camel jars to Kura distribution

We should discuss with a Kura community if they would like to have Camel jars included in the Kura distribution. We are talking about the following jars:

camel-core
camel-core-osgi
camel-kura

Probably also about:

camel-paho

Issued pull request - https://github.com/eclipse/kura/pull/69 .