Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 11:32
    nagytech edited #4091
  • 11:32
    nagytech opened #4091
  • 10:13
    nagytech commented #3954
  • 05:29
    nagytech commented #4090
  • 05:29
    nagytech opened #4090
  • Dec 11 23:52
    scptre commented #4082
  • Dec 11 14:26
    nagytech commented #3954
  • Dec 11 11:18
    nagytech edited #4089
  • Dec 11 11:17
    nagytech opened #4089
  • Dec 11 11:00
    nagytech commented #4083
  • Dec 11 08:34
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 08:33
    jiyeongj commented #4083
  • Dec 11 07:57

    dependabot-preview[bot] on nuget

    (compare)

  • Dec 11 07:57

    dependabot-preview[bot] on dev

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:57
    dependabot-preview[bot] closed #104
  • Dec 11 07:52
    dependabot-preview[bot] synchronize #104
  • Dec 11 07:52

    dependabot-preview[bot] on nuget

    Bump MongoDB.Driver from 2.9.1 … (compare)

  • Dec 11 07:52
    dependabot-preview[bot] edited #104
  • Dec 11 07:51
    dependabot-preview[bot] edited #104
Aaron Stannard
@Aaronontheweb
yes he was
I think there's a way that can be done generically too
David Smith
@smalldave
not sure how I feel about that. bit scary :)
Aaron Stannard
@Aaronontheweb
I was drafting a proof of concept idea for a talk @skotzko and I are giving later this month on doing Streaming ETL with Akka.NET
had the notion of allowing end users to install a NuGet package and write a .NET assembly that implements a few interfaces for doing Extract / Transform
and distributing that across the cluster - having specific actors deployed who use that code internerally since it knows how to construct objects with that interface
realized that you could just bake that code into the actor definitions themselves
the part that would suck is how you deal with updating an assembly you've already deployed once
I guess you'd need to have a registry on each node that its able to perform a CAS operation to do an in-place update
and some sort of coordinator responsible for making sure that all nodes eventually end up using the same binary
but then how do you kill off all of the actors deployed using the old stuff?
David Smith
@smalldave
you are making the f# approach sound less scary :)
Aaron Stannard
@Aaronontheweb
HAHA
yeah, I think maybe it's something that's a lot easier to do in F# :smile:
but that is the nasty edge case though
@smalldave newbie Topshelf question for you - is there any specific convention I need to follow when setting up commandline arguments?
like /mycommand {commandvalue}
David Smith
@smalldave
why do you want them for a service? when it's being installed?
Aaron Stannard
@Aaronontheweb
for when it's being installed
basically someone can pass in the IP, port number, and a debug flag that the service will use when it runs
David Smith
@smalldave
ok and you store it locally somewhere?
Aaron Stannard
@Aaronontheweb
Ideally I'd like it to be passed in each time in the service runs
David Smith
@smalldave
can't say I've done that before. usually just use config file
Aaron Stannard
@Aaronontheweb
as part of the service's command line
David Smith
@smalldave
ah. no idea if you can do that. I'm guessing not though
Aaron Stannard
@Aaronontheweb
actually, I guess this is mostly just for debugging
because the way this stuff really gets set is via .config
using the usual HOCON configuration stuff
David Smith
@smalldave
answer is I don't know. i guess topshelf will complain that it doesn't understand the parameters as it is trying to interpret them
should have read that properly. apparently doesn't work
Aaron Stannard
@Aaronontheweb
eh, in that case I'll just strip the commandline arguments out
they're all optional anyway
Aaron Stannard
@Aaronontheweb
anyone understand why the NLog logger wouldn't work with the following configuration?
<?xml version="1.0" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <targets>
    <!--<target name="eventlog" xsi:type="EventLog" layout="${logger}: ${message}" source="Lighthouse" log="Application" />-->
    <target name="console" xsi:type="ColoredConsole" layout="${date:format=HH\:MM\:ss} ${logger} ${message}"></target>
  </targets>

  <rules>
    <!--<logger name="*" minlevel="Warn" writeTo="eventlog" />-->
    <logger name="*" minlevel="Info" writeTo="console" />
  </rules>
</nlog>
commented out the eventlog stuff, but not seeing anything appear on the console
cc @mmisztal1980
David Smith
@smalldave
is that in nlog.config
Aaron Stannard
@Aaronontheweb
yes
David Smith
@smalldave
i just spent a while cursing logging because I didn't have always copy set on nlog.config
Aaron Stannard
@Aaronontheweb
welp, that fixed it
David Smith
@smalldave
hope that saved you the time I wasted
Aaron Stannard
@Aaronontheweb
I am hilariously inept at using third party logging tools
David Smith
@smalldave
;)
Aaron Stannard
@Aaronontheweb
it's one of those things where I went so long without having to set one up myself that I became too afraid to ask :worried:
Bartosz Sypytkowski
@Horusiath
do you guys think that open plugins proposals with up for grabs labels have sense?
David Smith
@smalldave
problem is that app.config web.config copy automatically. you forget that you have to opt in for other files
Aaron Stannard
@Aaronontheweb
@Horusiath totally - I think it'd be really cool if someone decided to write some of the persistence plugins you proposed
David Smith
@smalldave
agreed. can't do any harm
Aaron Stannard
@Aaronontheweb
yeah, the worst that can happen is someone submits something that doesn't work and the pull request doesn't get accepted