Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #38616 > unrolled thread
| Started by | mike <mikaelpetterson@hotmail.com> |
|---|---|
| First post | 2018-09-27 02:00 -0700 |
| Last post | 2018-09-27 14:01 +0200 |
| Articles | 4 — 4 participants |
Back to article view | Back to comp.lang.java.programmer
How to send files without blocking execution finish mike <mikaelpetterson@hotmail.com> - 2018-09-27 02:00 -0700
Re: How to send files without blocking execution finish Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-09-27 07:16 -0400
Re: How to send files without blocking execution finish Martin Gregorie <martin@mydomain.invalid> - 2018-09-27 11:40 +0000
Re: How to send files without blocking execution finish Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2018-09-27 14:01 +0200
| From | mike <mikaelpetterson@hotmail.com> |
|---|---|
| Date | 2018-09-27 02:00 -0700 |
| Subject | How to send files without blocking execution finish |
| Message-ID | <cd48f7c3-babb-4b65-bcd3-cce11b2ae5b2@googlegroups.com> |
Hi, We are creating a number of json files in our 'java test application'. Problem we have is that at the end of the execution we need to send all these json files to a different servers. This means the java application needs continue running until all files have been sent. This is really not part of the test and only make it look like the tests are still running ( or more holding up valuable execution time). Is there a way to start another jvm, from 'java test application' that runs a class that collects the json files and sends them to servers. If possible what will happen to new jvm if old 'java test application' finish execution? Or are there any other solutions to the problem? //mike
[toc] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2018-09-27 07:16 -0400 |
| Message-ID | <poie6t$9rk$1@dont-email.me> |
| In reply to | #38616 |
On 9/27/2018 5:00 AM, mike wrote:
> Hi,
>
> We are creating a number of json files in our 'java test application'.
>
> Problem we have is that at the end of the execution we need to send all these json files to a different servers. This means the java application needs continue running until all files have been sent. This is really not part of the test and only make it look like the tests are still running ( or more holding up valuable execution time).
>
> Is there a way to start another jvm, from 'java test application' that runs a class that collects the json files and sends them to servers. If possible what will happen to new jvm if old 'java test application' finish execution?
You could certainly use java.lang.ProcessBuilder to launch another
JVM, a process that would then execute independently of its launcher (if
you arrange for its standard input/output/error streams to go somewhere
else).
> Or are there any other solutions to the problem?
The most straightforward approach seems to be to send the files
from the application that creates them, either at the end or as
they're created. I'm not sure why you find this undesirable, but
here are two thoughts that might comfort you:
- If it's just a matter of the transmission time "inflating" the
overall run time and contaminating a timing-test result, perhaps you
could have the application announce "Finished creating at time T, now
moving on to transmission" and use time T as your end-of-test moment.
- "Holding up valuable execution time" seems a peculiar thing to
worry about. Transmission to other machines will almost surely be an
I/O-bound task, so even if it runs for quite a while it should chew
up very little CPU resource. Other programs should still be able to
get plenty of CPU even as the transmitter continues to run.
--
esosman@comcast-dot-net.invalid
Eight hundred forty-six days to go.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2018-09-27 11:40 +0000 |
| Message-ID | <poifk5$ph1$1@news.albasani.net> |
| In reply to | #38617 |
On Thu, 27 Sep 2018 07:16:43 -0400, Eric Sosman wrote: > - "Holding up valuable execution time" seems a peculiar thing to > worry about. Transmission to other machines will almost surely be an > I/O-bound task, so even if it runs for quite a while it should chew up > very little CPU resource. Other programs should still be able to get > plenty of CPU even as the transmitter continues to run. > Agreed. You could also add the JSON files to a queue serviced by one or more worker threads that send each request to the relevant server and deal with its response. If the JSON files are created at intervals rather than all of them in a burst this might even reduce execution time. -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2018-09-27 14:01 +0200 |
| Message-ID | <poigrk$pqq$1@dont-email.me> |
| In reply to | #38616 |
On 2018-09-27 11:00, mike wrote: > Hi, > > We are creating a number of json files in our 'java test application'. > > Problem we have is that at the end of the execution we need to send all these json files to a different servers. This means the java application needs continue running until all files have been sent. This is really not part of the test and only make it look like the tests are still running ( or more holding up valuable execution time). > > Is there a way to start another jvm, from 'java test application' that runs a class that collects the json files and sends them to servers. If possible what will happen to new jvm if old 'java test application' finish execution? > > Or are there any other solutions to the problem? If uploading those files is really not part of the test, then the test program shouldn't do it. To achieve that, I'd suggest abstracting out the component that does the upload, and inject it with a mock in the test configuration. This depends on what testing framework and DI you're using, if at all. -- DF.
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.java.programmer
csiph-web