Thread oder andere Alternative

Java-Forum
#1

Guten Morgen zusammen,

ich baue grad an einem Programm folgendes:

Thread holt aus der DB alle User (bis zu 1000), jeder User hat eine eigene Warenwirtschaft, welche per API gefüttert wird.

Nun mache ich jeden User in einem eigenen Thread, damit das ganze parallel läuft. Gibt es noch eine andere Lösung für solche Fälle?

#2

Ja, gibt es. Du machst einige Workerthreads, und sammelst in einer Queue die Arbeitspakete. Die Arbeitspakete beinhalten die Information zu welchen User sie gehören. Dadurch solltest du noch immer alles machen können, belegst aber für einen user der nichts zu tun hat keinen Thread.
Ach kannst du wenn du mehr last hast, die Arbeit auf meherer Systeme verteilen.

#3

Das klingt mega interessant, gibts ein Stichwort nach dem ich googlen kann? Nutze Spring Boot, gibt es vielleicht ein Framework dafür?

Edit:
Spring boot und Workerthreads googlen, bringt mir nur das, was ich grad schon habe einen Threadpool

#4

Naja prinzipiell ist das keine eigenen Technik oder ein eigenes Framewrork, sonder es ist eine Design- / Architekturentscheidung deinerseits.
Du hast geschrieben, dass du für jeden User einen eigenen Thread machen möchtest. Wie würdest du denn nun diesen Threads die Aufgaben die für einen User hereinkommen übergeben?
Wie findest du von der Rest API den richtigen Thread?

Wenn du das kurz beschreibst, dann könnten wir dir sagen wie du das vl umstellen kannst.

#5

https://spring.io/guides/gs/async-method/ könnte das passende sein.

Ansonsten ExecutorService + Runnable, mit Threads direkt zu arbeiten würde ich nach Möglichkeit vermeiden.

#6

Schau dir mal Spring Batch an.

2 Likes
#7

Das sieht schon mal gut aus! Ich habe folgende “Jobs”

Batch 1:

  1. Datei vom Hersteller holen (spezielles Format)
  2. Datei lesen und Pojo daraus bauen
  3. in die Datenbank speichern bzw der externen API übergeben (je nach Bedarf)

In den Tutorials die ich sehe, wird immer mit CSV gearbeitet, das sind aber nur Beispiele oder? Ich kann auch andere Steps bauen richtig?

#8

Du hast pro Step

Reader, Prozessoren, Writer

Was diese lesen, Verarbeiten und schreiben ist dir überlassen. Ein super Konzept, wie ich finde. Mit entsprechender protokollierung und alles,w as man für Enterprise Anwendungen braucht.

#9

Ah ok der Reader könnte also quasi auch was berechnen oder weiß der Kukuk was machen? Klingt sehr nach dem was ich brauche.

#10

Ohne jetzt die API dazu gelesen zu haben - auf Grund der Namen

Ein Reader sollte in der Tat nur lesen, wie der Namen es eben sagt. Für alles andere sollten die Prozessoren da sein.

#11

Wenn du sowas wie “leichtgewichtige Threads” brauchst, ist das Stichwort “Fiber”. Es gibt mehrere Bibliotheken dafür, z.B. Loom oder Quasar. Habe ich aber noch nicht ausprobiert.

#12

hab ich mir mal angesehen,

mit folgendem Code will ich pro User je einen “Fiber-Strang” parallelisieren. Macht er aber nicht, er macht alle User nacheinander.

@Autowired
ImportProcessor importProcessor    
public ResponseEntity<Object> runImport() {
		for (User user : userArray) {
				new Fiber<Void>(new SuspendableRunnable() {
					public void run() throws SuspendExecution, InterruptedException {
						importProcessor.runImport(user);
					}
				}).start();
			}
		}
		return new ResponseEntity<Object>(HttpStatus.OK);
	}

Jemand ne Idee?

#13

Wie gesagt, ich habe noch nicht mit quasar gearbeitet.

Die Doc sagt, dass man den DefaultFiberScheduler verwendet, wenn kein eigener gesetzt wird. Dort kann man die Zahl der Threads angeben, default ist die Anzahl der Cores:

http://docs.paralleluniverse.co/quasar/javadoc/co/paralleluniverse/fibers/DefaultFiberScheduler.html