I am currently working on a project in JAVA where I have to make an agent to interact with a server.
Each 50ms, the server will receive the last thing I outputted to System.out and send me a new set of lines as a 'state' through the System.in printstream to analyze and send my next message to System.out.
Also, if the server receives multiple outputs from me, it only regards the most recent one.
..
As for my question:
My program originally constructed a tree and then analyzed each leaf node to see which would be optimal, and then waited around for the next input, but I can recursively do a deeper tree search that would make my output 'better' (and again and again to keep returning a better result).
Using this and the fact that if the server receives multiple outputs, it only takes the most recent one, I could do each level, print my result and start the next level. But here comes my problem...
I can't be stuck in some complex algorithm while I am supposed to receiving the next input as I will then miss it. So I was wondering if there is a way to cancel anything else I am doing when I receive something via System.in and then go back to the beginning of the function and start the search again with the new set of input (and rinse and repeat..)
I hope this all makes sense,
Thank ye all
You absolutely require either multiple threads (or multiple processes) here.
I assume that you've solved the problem of receiving input into System.in, as well as the problem of your algorithm. The next step is to package each in a Runnable interface, and hand each a reference to a queuing object. This will scaffold a Producer-Consumer relationship.
Whenever your listening Runnable (the Producer) gets a message, it needs to put it on your queue. After every unit of work, your algorithm (the Consumer) should look into the queue for items that are there. If it finds something, it should integrate it as normal. If not, it continues on with it's work.
Both the Producer and the Consumer need to be started in their own threads and allowed to run concurrently.
Related
Scenario
There is a factory that receives orders. Once received, every order item goes through a multi-step production process. Every step is done by a separate machine and every machine can only handle one item at a time. So the order comes in, the first item goes to machine1, when it's done it goes to machine2 and the next item to machine1, etc.
Technical part
Every machine is implemented as a thread and has a queue with all items lined up that need this step of the process next. The run method of the machine checks in an endless while loop if there is anything in the queue, if yes it will handle that item, sleep for a certain amount of time and then push the item to the queue of the next machine.
Questions
In my head, this sounds all pretty simple. But I constantly run into null-pointer errors and other weird exceptions. I honestly don't fully understand what's wrong but I suspect it's a problem with multi-threading vs. sleep. At this point I got two questions:
What happens if I call a method of a sleeping thread (machine)? (Example: I call machine.addItemToQueue() while that machine is working on another item).
Follows Q1: Let's say I really can't call that method while the machine 'sleeps'. How else would I handle this? Should I take the queue outside the machine? Is this an async problem?
I have two (Java) processes on different JVMs running repeatedly. The first one regularly finds some "information" and needs to store it somewhere. The second process regularly reads this information to handle it. The intervals are more or less random, so process 1 may find three pieces of information until process 2 reads them or vice versa.
My approach is to write this information to text files. But I am afraid that appending and reading the text files accidentally happens at the same time so that I run into locks. But writing a new text file for each piece of information seems like overkill.
What would be a better solution?
EDIT: I am sorry, I did not make clear: The java processes run in different JVMs. They cannot see each other directly.
You can get this to work, provided you are careful with file handling and you don't have a high update rate e.g. 10 updates per second.
Note: you could do it with file renaming instead of locks.
What would be a better solution?
Just about anything, SO is not for recommending things, but in this case I could recommend just about anything without more specific requirements. I could for example recommend my library Chronicle Queue because I wrote it and I sure it could do what you want, however there are many possible alternatives.
I am sending about one line of text every minute.
So you can write a temporary file for each message, rename it when finished. The consumer can have a directory watcher so it knows as soon as you have done this. The consumer could delete the file when done. This has an overhead but it would be less than 10 ms.
If you want to keep a record of all messages, the producer can also write to a log file.
I have a process that splits into many different branches. The business requirement is that at any step, the process has to sent back to the process originator for correction and re-approval.
I know it would be possible to to use gateway logic at the end of each step and have the process return to the beginning that way; however, this would add many lines and branches to the process so that it would be incredibly difficult to read. I was thinking that an alternate way to accomplish this would be to simply abort the process and restart based on the information in the existing process - this seems more maintainable.
Both of these would not be too hard to implement, but I am wondering if there is an easier way to achieve this goal. I have not worked with signals much, but is there a way to leverage that to return to a previous step in the process?
Start of Editted Solution
Based on #Kris Verlaenen suggestion, it created the example process below.
I started by putting all of the steps that can be might be skipped into an Embedded SubProcess. The Return, Rejection, and Cancel signals were added from the Boundary Events tab of the palette. While the process waits for the Supervisor or Manager approval to complete, you can send a either of the signals to either go back to the first step or jump to the end of the process.
Using a event sub-process could allow you to trigger some part of your process every time the event occurs (could be signal, error, etc.)
Using an embedded sub-process with boundary event might help, as that way you would only have to link back grom that boundary event to the start, and whenever a signal / error occurs inside the sub-process, the boundary event could catch this. You could even make it interrupting, meaning it would cancel anything inside the sub-process as well, basically resetting what you were doing.
I'm not sure if this is the right way, please correct me if it's not:
In main loop, I poll events like this:
Keyboard.poll();
Mouse.poll();
// process the events
Then at the end of the main loop, I have Display.update() to swap buffers etc, and Display.sync(60) to keep FPS.
Now the question is, since Display.update() apparently also polls inputs, does this mean I'm going to lose some events? Should I remove the additional poll's and rely on Display.update()?
You can call Display.update(false), which does not poll inputs. However if you do, poll by calling Display.processMessages(), not individual devices.
I have many threads performing different operations on object and when nearly 50% of the task finished then I want to serialize everything(might be I want to shut down my machine ).
When I come back then I want to start from the point where I had left.
How can we achieve?
This is like saving state of objects of any game while playing.
Normally we save the state of the object and retrieve back. But here we are storing its process's count/state.
For example:
I am having a thread which is creating salary excel sheet for 50 thousand employee.
Other thread is creating appraisal letters for same 50 thousand employee.
Another thread is writing "Happy New Year" e-mail to 50 thousand employee.
so imagine multiple operations.
Now I want to shut down in between 50% of task finishes. say 25-30 thousand employee salary excel-sheet have been written and appraisal letters done for 25-30 thousand and so on.
When I will come back next day then I want to start the process from where I had left.
This is like resume.
I'm not sure if this might help, but you can achieve this if the threads communicate via in-memory queues.
To serialize the whole application, what you need to do is to disable the consumption of the queues, and when all the threads are idle you'll reach a "safe-point" where you can serialize the whole state. You'll need to keep track of all the threads you spawn, to know if they are in are idle.
You might be able to do this with another technology (maybe a java agent?) that freezes the JVM and allows you to dump the whole state, but I don't know if this exists.
well its not much different than saving state of object.
just maintain separate queues for different kind of inputs. and on every launch (1st launch or relaunch) check those queues, if not empty resume your 'stopped process' by starting new process but with remaining data.
say for ex. an app is sending messages, and u quit the app with 10 msg remaining. Have a global queue, which the app's senderMethod will check on every launch. so in this case it will have 10msg in pending queue, so it will continue sending remaining msgs.
Edit:
basically, for all resumable process' say pr1, pr2....prN, maintain queue of inputs, say q1, q2..... qN. queue should remove processed elements, to contain only pending inputs. as soon as u suspend system. store these queues, and on relaunching restore them. have a common routine say resumeOperation, which will call all resumable process (pr1, pr2....prN). So it will trigger the execution of methods with non-0 queues. which in tern replicate resuming behavior.
Java provides the java.io.Serializable interface to indicate serialization support in classes.
You don't provide much information about the task, so it's difficult to give an answer.
One way to think about a task is in terms of a general algorithm which can split in several steps. Each of these steps in turn are tasks themselves, so you should see a pattern here.
By cutting down each algorithms in small pieces until you cannot divide further you get a pretty good idea of where your task can be interrupted and recovered later.
The result of a task can be:
a success: the task returns a value of the expected type
a failure: somehow, something didn't turn right while doing computation
an interrupted computation: the work wasn't finished, but it may be resumed later, and the return value is the state of the task
(Note that the later case could be considered a subcase of a failure, it's up to you to organize your protocol as you see fit).
Depending on how you generate the interruption event (will it be a message passed from the main thread to the worker threads? Will it be an exception?), that event will have to bubble within the task tree, and trigger each task to evaluate if its work can be resumed or not, and then provide a serialized version of itself to the larger task containing it.
I don't think serialization is the correct approach to this problem. What you want is persistent queues, which you remove an item from when you've processed it. Every time you start the program you just start processing the queue from the beginning. There are numerous ways of implementing a persistent queue, but a database comes to mind given the scale of your operations.