Java Multithreaded Network API (discussion)

#21

I’m not sure I understand what you want. At the lowest level (the physical cable running between the server and your switch) the network card is going to be acting in a manner that could be seen as ‘single-threaded’.
Specifically, it’s going to be dispatching a series of IP packets in a spray-and-pray fashion, and the higher level (TCP) will take care of detecting loss and re-dispatch.

The key indicators of performance you guys should be looking at are throughput (i.e., MB/s sent over the network card) and latency (average and max - the max latency is where Java enters into a GC cycle and underperforms). These need to be measured by a third-party widget (not the JVM you’re running your code on).

Going back to real-time systems, you’ll also want to measure jitter. That’s essentially deviation from the average (i.e., the difference between your min/max and your average latency above).

In the worst case, perhaps you guys should fork Netty and make the changes there, not that I understand the change particularly well. At least then you’ll have a reasonable starting point instead of building it from scratch (know that thousands of hours have gone into Netty - that’s hundreds of thousands of dollars in salaries for a business).

#22

nice meme

#23

It’s not about the lowest layer, that is already optimum. The system could be the only bottle neck right now hence we want to be able to handle clients, as many as possible at the same time.

The reason we don’t fork netty directly is because some of us don’t like a lot of how things are done. This is natural to some developers to have pet peeves. The most we’ll do is reference netty or even use some of it’s features.

Try not to think of the deeper issue here. Physical layer, programming language of choice etc etc is not up for discussion.

#24

i don’t get what this topic is about. you’re proposing a solution to a problem, you wont tell us clearly what the problem is you’re trying to solve, and you don’t want to hear our feedback. what exactly do you want to discuss?

#25

So what did you want from us? Validation? If things aren’t up for discussion then that’s fine, but why create a discussion?

Developers do have pet peeves, sure. A sane business won’t bin something because of pet peeves though. Instead, where is someone to tell these developers to cop onto themselves and deal with it?

Anyway, whatever works. If your business can tolerate the cost of developing, testing and supporting a component instead of buying one off the shelf or using an open-source one then that’s fine.

#26

In my short lived thus far career as a professional software engineer, here’s my honest advice - shut up and just do what your superiors tell you. Use whatever the fuck libraries they decide to use, but let them decide.

#27
#28

[quote=“Tree, post:27, topic:555343”][quote author=Yz85Racer link=topic=674535.msg4508507#msg4508507 date=1463194564]
In my short lived thus far career as a professional software engineer, here’s my honest advice - shut up and just do what your superiors tell you. Use whatever the fudge libraries they decide to use, but let them decide.
[/quote][/quote]