GrumpyDoctor posted:

What have you tried, and what's not working?

mortarr posted:

I was treating c# like javascript and it turns out if I do a Post instead of a Get I can JSON.stringify() my object and send it up as post data, and then it's all sweet from there. Can't believe I wasted like four hours on this poo poo.

mortarr posted:

Can't believe I wasted like four hours on this poo poo.

mortarr posted:

I was treating c# like javascript and it turns out if I do a Post instead of a Get I can JSON.stringify() my object and send it up as post data, and then it's all sweet from there. Can't believe I wasted like four hours on this poo poo.

epalm posted:

I've run into this before. My request should definitely be a GET, but the data I'm sending is complex (an array of objects with properties) and just doesn't work with GET, but does work with POST. When I say "doesn't work" I mean the IEnumerable arg is null.

So at the time I just called it a day and used POST.

But...what up with that?

epalm posted:

In both scenarios data is being "sent", whether I GET or POST /page.html?searchTerm=poop

The idea between GET and POST, is that GET should have no server-side side effects (search for something, get back results), whereas POST may have server-side side effects (save this record).

My question is why can't I use GET and send a complex type? For example say I'm running a search with a list search terms.

epalm posted:

My question is why can't I use GET and send a complex type? For example say I'm running a search with a list search terms.

epalm posted:

JavaScript code:

rows = [
    { Id: 42, Qty: 2 },
    { Id: 44, Qty: 2 },
    { Id: 48, Qty: 4 },
];

$.ajax({
    url: "/path/to/mymethod",
    type: 'POST',
    contentType: "application/json",
    dataType: "html",
    data: JSON.stringify({ model: rows }),
});

C# code:

[HttpPost]
public PartialViewResult MyMethod(int expId, IEnumerable<Row> model)
{
    return PartialView("...");
}

public class Row
{
    public int Id { get; set; }
    public int Qty { get; set; }
}

The above, using POST, works like a charm. Technically I "should" be using GET because I'm just requesting some data/visuals, and the call to MyMethod has no side effects.

If I change type: 'POST', to type: 'GET',
and [HttpPost] to [HttpGet]
then MyMethods model argument will inexplicably be null

Bognar posted:

Generally, you shouldn't JSON.stringify if you're using jQuery AJAX to GET. GET commands are (de)serialized as application/x-www-form-urlencoded because they have to be part of the query string (GET request bodies are ignored per the HTTP/1.1 spec). POST requests, on the other hand, can have anything in the body and will usually work on most servers as long as the Content-Type header is correct (e.g. application/json).

Unfortunately, the default MVC model binder is rather terrible at deserializing complex objects from a query string. A lot of things have to fall into place to make it work, and it's generally not worth figuring it out over just POSTing.

ljw1004 posted:

It looks like TextFieldParser doesn't actually buy you much in this situation, and is more trouble than it's worth. I'd do it like this:

code:

Using afile As New IO.StreamReader("TextFile1.csv")
    afile.ReadLine() ' discard the first row, which contains column headings
    While Not afile.EndOfStream
        Dim line = afile.ReadLine()
        Dim csv = line.Split(","c)
        If csv.Count <> 3 Then Continue While
        Console.WriteLine("{0}...{1}...{2}", csv(0), csv(1), csv(2))
    End While
End Using

You'll need some heuristic for how to detect column headings, and blank lines, and subtitles. In your code your heuristic was to look for the exact content. I picked different heuristics in the hope that they'd be more general (i.e. wouldn't need you rewriting your code when the CSV starts looking slightly different).

Bognar posted:

Generally, you shouldn't JSON.stringify if you're using jQuery AJAX to GET. GET commands are (de)serialized as application/x-www-form-urlencoded because they have to be part of the query string

ljw1004 posted:

...

Mr. Crow posted:

Missed opportunity to

Factor Mystic posted:

What's a good technique to parallelize a recursive, async retrieval task? I'm loading hierarchical items (folders of items & folders) from a remote resource, and there's wait time associated with getting a folder's children.
...
Doing something like "await Task.WhenAll(folders.Select(LoadStuff))" seems to balloon the number of threads in use, but I assume that's capped by thread pool availability anyway.

quote:

epalm posted:

I understand what you're all saying.

EssOEss posted:

Right. The reason for this separate box is not to make life for you easy, it is to make life easy for the colleagues who have to work with your stuff.

Installing real IIS on your PC is just an answer to your question, it is not the solution to your problem.

RICHUNCLEPENNYBAGS posted:

So for people for do this how do you handle different branches working with modified database schemas?

ljw1004 posted:

"Balloon the number of threads" is a surprise to me. The await operator doesn't create new threads. Task.WhenAll doesn't create new threads. The general principle is that no keywords in C# create new threads, and only a few specific clearly-identified functions like "Task.Run" will allocate anything on the threadpool. So where did your mysterious ballooning threads come from? I don't know. There might have been other threads being used under the hood, due to misbehaved APIs, but it's hard to know without a debugger.

ljw1004 posted:

Stepping back, let's examine the problem from a theoretical angle. By the time your algorithm completes you will have issued "N" total calls to the remote resource and they will have completed. No amount of parallelization will ever change this total number "N".

You believe that your remote resource can typically handle a higher rate of concurrent requests than just simply doing those N requests one after the other. This is a reasonable belief and true of most servers. So what is the optimum number of parallel requests? Impossible to say. We don't know if the server will be fielding requests from other clients at the same time. We don't know if the server will reject requests if it's busy, or queue them up. It's likely not a good use of resources to implement our own rate-adjusting throttling mechanism to determine on-the-fly the optimum number of requests (like the throttler in TCP/IP does).

ljw1004 posted:

The best practical answer, one that works great in most situations, is just pick a number. Let's say "3" parallel requests. If the server takes time "t" for each request, then you'll finish in about N*t/3.


Here are two idioms for throttling async stuff. The first looks stupid, but it's clear and works and doesn't need new abstractions and is robust, and that in my book is a good pattern If you run it all on the UI thread then you don't even need to worry about using concurrency-safe data structures. For instance, you can use a normal (non-concurrent) queue, and your ProcessWorkItem method can happily add things to an ObservableCollection that's databound to the UI.

code:

async void Button1_Click() {
    var t1 = WorkerAsync();
    var t2 = WorkerAsync();
    var t3 = WorkerAsync();
    await Task.WhenAll(t1,t2,t3);
}

async Task WorkerAsync() {
   while (queue.Count>0) {
      var i = queue.Dequeue();
      ProcessWorkItem(i);
   }
}

In your case, you described your problem recursively, but I've implemented it non-recursively. Just make a queue of all outstanding folders that have yet to be processed. In your "ProcessWorkItem" function, you can retrieve all child folders, add them to the queue, then retrieve all child files.

ljw1004 posted:

Here's another solution for throttling based on the "Dataflow" library from Microsoft. Dataflow is powerful and you can wire it up in more sophisticated ways. It runs the callbacks on the threadpool. But again, you're still turning the recursive thing into something queue-based.

code:

private static async Task LotsOfWorkAsync()
{
    ITargetBlock<Folder> throttle = null;
    throttle = Throttle<Folder>(
        async folder =>
        {
            // handle the folder by posting further folders to the throttle
        },
        maxParallelism: 3);
    throttle.Post(top_level_folder);

    // Signal that we're done enqueuing work.
    // Actually, I don't know where best to call this function.
    // You'd call it when there are no more items left to enqueue.
    // I don't know how to figure that out cleanly.
    //throttle.Complete();

    // Don't complete this async method until the queue is fully processed.
    await throttle.Completion;
}

private static ITargetBlock<T> Throttle<T>(Func<T, Task> worker, int maxParallelism)
{
    var block = new ActionBlock<T>(worker,
        new ExecutionDataflowBlockOptions {
            MaxDegreeOfParallelism = maxParallelism,
        });
    return block;
}

RICHUNCLEPENNYBAGS posted:

So for people for do this how do you handle different branches working with modified database schemas?

candy for breakfast posted:

Nthing everyone else here: WPF/MVVM is not easy. It took all of us some time to understand it. Once you hit that 'aha' moment then you realize it turns into something spectacular and never want to go back to winforms.

I helped someone convert their example program to proper MVVM in another thread. Granted the dealer hitting/staying logic doesn't work, but it's a simple example of INotifyPropertyChanged, RelayCommand, and datacontext implementations.

Factor Mystic posted:

I don't know either. Perhaps I was misreading the my debug print statements, which also print the current Environment.CurrentManagedThreadId. Normally the highest id's I see are 7-8. With the WhenAll approach, the id's climbed steadily up into the 80's before I killed the process.

I suppose my report could be inaccurate if the managed thread id doesn't reliably indicate which native thread is running and could tick higher even when reusing the same native thread at a later point, but poking around the reference source sure seems to imply that it's referring to a native thread.

quote:

Yes, this seems like the most obvious approach, however I believe it'll be preferable to run queue consumption on another thread. (A detail which I left out of my example case is that this code is already running on a background Task thread, not on the UI thread. Since this is really more of a patterns question, it didn't seem super relevant. The reason is UI responsiveness. The OC<T> in my example is not databound in the UI. Not relevant details for a pattern question).

ljw1004 posted:

I'm not sure which reference source you're looking at? The .NET reference source only says that the getter of CurretManagedThreadId is "extern". In any case, when you look at the debugger window, you usually see higher CurrentManagedThreadId than there are threads. This proves either that your way of testing isn't accurate or that the VS debugger fails to show all threads. I reckon the way of testing isn't accurate

ljw1004 posted:

I reckon there's almost never a good reason to run your work on a background thread, and lots of bad reasons. Here are slides from a recent talk I gave to the Windows XAML team:






FACT: doing asynchronous work on the UI thread, i.e. using the await operator, will NEVER harm UI responsiveness, not even on the lowest-power device you'll find. The only things that harm responsiveness are when you have "10s" or "100s" concurrency (e.g. if you throttle up to 100 concurrent requests). Or when you have code which blocks a thread.

The only code that blocks a thread is (1) calling blocking APIs - in which case rewrite your code to use async APIs; or (2) doing a CPU-bound computational kernel - in which case do this small computational kernel inside Task.Run.

What you can end up with is an architecture where the orchestration of the app is done entirely on a single thread (i.e. all the awaiting, data-binding, app-logic, ...). And only the small computational inner-loops are done on the threadpool using Task.Run. This architecture will have fewer concurrency bugs and easier-to-read code.

GrumpyDoctor posted:

edit: There had better be a better way to do this, as I am apparently unable to actually catch this exception. No matter where I put try/catch blocks, the exception slips through and brings my app down.