Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #38616 > unrolled thread

How to send files without blocking execution finish

Started bymike <mikaelpetterson@hotmail.com>
First post2018-09-27 02:00 -0700
Last post2018-09-27 14:01 +0200
Articles 4 — 4 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  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

#38616 — How to send files without blocking execution finish

Frommike <mikaelpetterson@hotmail.com>
Date2018-09-27 02:00 -0700
SubjectHow 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]


#38617

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2018-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]


#38618

FromMartin Gregorie <martin@mydomain.invalid>
Date2018-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]


#38619

FromDaniele Futtorovic <da.futt.news@laposte-dot-net.invalid>
Date2018-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