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

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

interruptable process?

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

Contents

  interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-08 05:27 -0700
    Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 09:50 -0400
      Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-08 07:39 -0700
        Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 14:27 -0400
          Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-08 11:58 -0700
            Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 15:10 -0400
            Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 15:22 -0400
              Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-08 12:40 -0700
                Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 16:21 -0400
                  Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 16:55 -0400
                    Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-08 21:15 -0400
                      Re: interruptable process? Martin Gregorie <martin@address-in-sig.invalid> - 2015-10-09 09:41 +0000
                        Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 05:12 -0700
                          Re: interruptable process? Martin Gregorie <martin@address-in-sig.invalid> - 2015-10-09 13:52 +0000
                            Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 09:08 -0700
                              Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 12:43 -0400
                                Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 13:23 -0400
                          Re: interruptable process? Jan Burse <janburse@fastmail.fm> - 2015-10-09 18:26 +0200
                            Re: interruptable process? Jan Burse <janburse@fastmail.fm> - 2015-10-09 18:30 +0200
                              Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 10:31 -0700
                                Re: interruptable process? Martin Gregorie <martin@address-in-sig.invalid> - 2015-10-09 23:13 +0000
                                  Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-12 05:09 -0700
                            Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 10:25 -0700
                              Re: interruptable process? Jan Burse <janburse@fastmail.fm> - 2015-10-09 20:04 +0200
                                Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 11:23 -0700
                                  Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 11:30 -0700
                        Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 08:38 -0400
                    Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 05:18 -0700
                      Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 08:46 -0400
                        Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 08:59 -0400
                          Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 11:06 -0400
                            Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 13:54 -0400
                              Re: interruptable process? Jeff Higgins <jeff@invalid.invalid> - 2015-10-09 14:59 -0400
                                Re: interruptable process? Eric Douglas <e.d.programmer@gmail.com> - 2015-10-09 12:13 -0700

Page 1 of 2  [1] 2  Next page →

#32832 — interruptable process?

We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.

What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?

[toc] | [next] | [standalone]

#32833

On 10/08/2015 08:27 AM, Eric Douglas wrote:
> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
>
> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
>

<https://github.com/GSORF/renderfarm>

[toc] | [prev] | [next] | [standalone]

#32834

On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
> On 10/08/2015 08:27 AM, Eric Douglas wrote:
> > We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
> >
> > What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
> >
> 
> <https://github.com/GSORF/renderfarm>

That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.

[toc] | [prev] | [next] | [standalone]

#32835

On 10/08/2015 10:39 AM, Eric Douglas wrote:
> On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
>> On 10/08/2015 08:27 AM, Eric Douglas wrote:
>>> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
>>>
>>> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
>>>
>>
>> <https://github.com/GSORF/renderfarm>
>
> That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.
>

I guess I'm missing something.

SCRIPT spins waiting for JOB REQUESTS.

JOB REQUEST ::=
REQUESTOR_ID
JOB_ID
JOB_DESCRIPTION

JEFF, 00989, PROCESS BLENDFILEPATH : OUTPUT OUTPATH : NOTIFY COMPLETION

JEFF, 00989, CANCEL

[toc] | [prev] | [next] | [standalone]

#32836

On Thursday, October 8, 2015 at 2:28:07 PM UTC-4, Jeff Higgins wrote:
> On 10/08/2015 10:39 AM, Eric Douglas wrote:
> > On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
> >> On 10/08/2015 08:27 AM, Eric Douglas wrote:
> >>> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
> >>>
> >>> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
> >>>
> >>
> >> <https://github.com/GSORF/renderfarm>
> >
> > That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.
> >
> 
> I guess I'm missing something.
> 
> SCRIPT spins waiting for JOB REQUESTS.
> 
> JOB REQUEST ::=
> REQUESTOR_ID
> JOB_ID
> JOB_DESCRIPTION
> 
> JEFF, 00989, PROCESS BLENDFILEPATH : OUTPUT OUTPATH : NOTIFY COMPLETION
> 
> JEFF, 00989, CANCEL

on the GSORF?  I didn't test the program but it wasn't obvious from the 'how to' pages if or how you can cancel a render currently in progress.

[toc] | [prev] | [next] | [standalone]

#32837

On 10/08/2015 02:58 PM, Eric Douglas wrote:
> On Thursday, October 8, 2015 at 2:28:07 PM UTC-4, Jeff Higgins wrote:
>> On 10/08/2015 10:39 AM, Eric Douglas wrote:
>>> On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
>>>> On 10/08/2015 08:27 AM, Eric Douglas wrote:
>>>>> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
>>>>>
>>>>> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
>>>>>
>>>>
>>>> <https://github.com/GSORF/renderfarm>
>>>
>>> That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.
>>>
>>
>> I guess I'm missing something.
>>
>> SCRIPT spins waiting for JOB REQUESTS.
>>
>> JOB REQUEST ::=
>> REQUESTOR_ID
>> JOB_ID
>> JOB_DESCRIPTION
>>
>> JEFF, 00989, PROCESS BLENDFILEPATH : OUTPUT OUTPATH : NOTIFY COMPLETION
>>
>> JEFF, 00989, CANCEL
>
> on the GSORF?  I didn't test the program but it wasn't obvious from the 'how to' pages if or how you can cancel a render currently in progress.
>

on the GSORF?

No.
You asked:
"What could be the best way to rewrite this?"

Only you know.

If you want your user to be able to communicate with
the processor then they will need a communications channel.

Drop a poison pill in the directory?
Who knows? You.

[toc] | [prev] | [next] | [standalone]

#32838

On 10/08/2015 02:58 PM, Eric Douglas wrote:
> On Thursday, October 8, 2015 at 2:28:07 PM UTC-4, Jeff Higgins wrote:
>> On 10/08/2015 10:39 AM, Eric Douglas wrote:
>>> On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
>>>> On 10/08/2015 08:27 AM, Eric Douglas wrote:
>>>>> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
>>>>>
>>>>> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
>>>>>
>>>>
>>>> <https://github.com/GSORF/renderfarm>
>>>
>>> That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.
>>>
>>
>> I guess I'm missing something.
>>
>> SCRIPT spins waiting for JOB REQUESTS.
>>
>> JOB REQUEST ::=
>> REQUESTOR_ID
>> JOB_ID
>> JOB_DESCRIPTION
>>
>> JEFF, 00989, PROCESS BLENDFILEPATH : OUTPUT OUTPATH : NOTIFY COMPLETION
>>
>> JEFF, 00989, CANCEL
>
> on the GSORF?  I didn't test the program but it wasn't obvious from the 'how to' pages if or how you can cancel a render currently in progress.
>
Just out of curosity, and since you mention
"we're running a command (ie DOS) script".
Are you using PowerShell?

[toc] | [prev] | [next] | [standalone]

#32839

On Thursday, October 8, 2015 at 3:23:10 PM UTC-4, Jeff Higgins wrote:
> On 10/08/2015 02:58 PM, Eric Douglas wrote:
> > On Thursday, October 8, 2015 at 2:28:07 PM UTC-4, Jeff Higgins wrote:
> >> On 10/08/2015 10:39 AM, Eric Douglas wrote:
> >>> On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
> >>>> On 10/08/2015 08:27 AM, Eric Douglas wrote:
> >>>>> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
> >>>>>
> >>>>> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
> >>>>>
> >>>>
> >>>> <https://github.com/GSORF/renderfarm>
> >>>
> >>> That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.
> >>>
> >>
> >> I guess I'm missing something.
> >>
> >> SCRIPT spins waiting for JOB REQUESTS.
> >>
> >> JOB REQUEST ::=
> >> REQUESTOR_ID
> >> JOB_ID
> >> JOB_DESCRIPTION
> >>
> >> JEFF, 00989, PROCESS BLENDFILEPATH : OUTPUT OUTPATH : NOTIFY COMPLETION
> >>
> >> JEFF, 00989, CANCEL
> >
> > on the GSORF?  I didn't test the program but it wasn't obvious from the 'how to' pages if or how you can cancel a render currently in progress.
> >
> Just out of curosity, and since you mention
> "we're running a command (ie DOS) script".
> Are you using PowerShell?

Nope, just a straight up cmd.exe with a .bat file.
This works ok for running on the server but doesn't allow remote interaction, so we need some method to abort the current render from another machine on the domain.

I can write 2 runnable jars, one with listening threads for the server and one to process commands for the client, then I need to find how to kill the current running task (system command) called from a jar.  I'm currently looking at the Capitalization sample for the client-server connection. http://cs.lmu.edu/~ray/notes/javanetexamples/

The .bat file currently runs "java.exe - jar" one time on a runnable jar, and that jar program has an infinite loop to execute commands using java.lang.ProcessBuilder when it finds files in a folder it checks every 30 seconds.
Since this Java program is started with java.exe, not javaw, from a cmd.exe window, we just select that window and hit ctrl + break currently to stop a render - which stops that current process called from the Java program without killing the program so it continues it's loop.

I don't know if all this even makes sense or there's an easier way to start processes on a machine that can be aborted from another machine.

[toc] | [prev] | [next] | [standalone]

#32840

On 10/08/2015 03:40 PM, Eric Douglas wrote:
> On Thursday, October 8, 2015 at 3:23:10 PM UTC-4, Jeff Higgins wrote:
>> On 10/08/2015 02:58 PM, Eric Douglas wrote:
>>> On Thursday, October 8, 2015 at 2:28:07 PM UTC-4, Jeff Higgins wrote:
>>>> On 10/08/2015 10:39 AM, Eric Douglas wrote:
>>>>> On Thursday, October 8, 2015 at 9:51:16 AM UTC-4, Jeff Higgins wrote:
>>>>>> On 10/08/2015 08:27 AM, Eric Douglas wrote:
>>>>>>> We currently have an admin user logged into a server.  In that user's session we're running a command (ie DOS) script.  That script runs an infinite loop.  In each iteration of the loop it checks a folder for files.  If it finds files it starts a Blender process to render one.  If we need to cancel a render, we log on to that server and connect to that session, select that command window and press ctrl + break, then delete the file.  The loop continues checking for files.
>>>>>>>
>>>>>>> What could be the best way to rewrite this?  We need this to be a background process which allows a user to remotely cancel the render from their pc.  I could do this with a Java program, or is there a scripting version that makes sense?
>>>>>>>
>>>>>>
>>>>>> <https://github.com/GSORF/renderfarm>
>>>>>
>>>>> That looks very interesting, but currently we're only using the one server machine to render (SLI, Geforce 970 x 2).  The user drops blend files into a folder and a process on the server checks for them and starts a new render if it's not already running one.  The user needs to be able to stop a render in progress (I didn't see that option in GSORF), and it should auto-delete the input to look for a new one.
>>>>>
>>>>
>>>> I guess I'm missing something.
>>>>
>>>> SCRIPT spins waiting for JOB REQUESTS.
>>>>
>>>> JOB REQUEST ::=
>>>> REQUESTOR_ID
>>>> JOB_ID
>>>> JOB_DESCRIPTION
>>>>
>>>> JEFF, 00989, PROCESS BLENDFILEPATH : OUTPUT OUTPATH : NOTIFY COMPLETION
>>>>
>>>> JEFF, 00989, CANCEL
>>>
>>> on the GSORF?  I didn't test the program but it wasn't obvious from the 'how to' pages if or how you can cancel a render currently in progress.
>>>
>> Just out of curosity, and since you mention
>> "we're running a command (ie DOS) script".
>> Are you using PowerShell?
>
> Nope, just a straight up cmd.exe with a .bat file.
> This works ok for running on the server but doesn't allow remote interaction, so we need some method to abort the current render from another machine on the domain.
>
> I can write 2 runnable jars, one with listening threads for the server and one to process commands for the client, then I need to find how to kill the current running task (system command) called from a jar.  I'm currently looking at the Capitalization sample for the client-server connection. http://cs.lmu.edu/~ray/notes/javanetexamples/
>

RenderJob Protocol

Client requests job ticket.
Server sends job ticket to client.
Client sends completed job ticket to server.
{Please process these blender files, and notify when I can pick them up.}
Server begins job.
Client requests another job ticket.
Server sends job ticket to client.
Client sends completed job ticket to server.
{Please cancel job ticket  00989}

It would be very easy to modify your Capitalization
sample to run on your own RenderJob Protocol.


> The .bat file currently runs "java.exe - jar" one time on a runnable jar, and that jar program has an infinite loop to execute commands using java.lang.ProcessBuilder when it finds files in a folder it checks every 30 seconds.
> Since this Java program is started with java.exe, not javaw, from a cmd.exe window, we just select that window and hit ctrl + break currently to stop a render - which stops that current process called from the Java program without killing the program so it continues it's loop.
>

You mean that a body clicks a button in a window?
What happens when he's taking a break?

> I don't know if all this even makes sense or there's an easier way to start processes on a machine that can be aborted from another machine.
>

[toc] | [prev] | [next] | [standalone]

#32841

On 10/08/2015 04:21 PM, Jeff Higgins wrote:

>> I don't know if all this even makes sense or there's an easier way to
>> start processes on a machine that can be aborted from another machine.
>>

I'm not really sure why Java platform anyway.

<http://windowsitpro.com/powershell/break-your-batch-habit-and-move-powershell>

<https://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx>

[toc] | [prev] | [next] | [standalone]

#32842

On 10/08/2015 04:55 PM, Jeff Higgins wrote:
> On 10/08/2015 04:21 PM, Jeff Higgins wrote:
>
>>> I don't know if all this even makes sense or there's an easier way to
>>> start processes on a machine that can be aborted from another machine.
>>>
>
> I'm not really sure why Java platform anyway.
>
> <http://windowsitpro.com/powershell/break-your-batch-habit-and-move-powershell>
>
>
> <https://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx>
>
If using the OS services to kill a running blender instance seems drastic.

Maybe you can finesse it with some python scripting.
<http://www.blender.org/api/blender_python_api_2_76_1/bpy.app.handlers.html>

You'll still want a way to communicate.
Maybe Jetty or Tomcat.

[toc] | [prev] | [next] | [standalone]

#32843

On Thu, 08 Oct 2015 21:15:30 -0400, Jeff Higgins wrote:

> On 10/08/2015 04:55 PM, Jeff Higgins wrote:
>> On 10/08/2015 04:21 PM, Jeff Higgins wrote:
>>
>>>> I don't know if all this even makes sense or there's an easier way to
>>>> start processes on a machine that can be aborted from another
>>>> machine.
>>>>
>>>>
>> I'm not really sure why Java platform anyway.
>>
>> <http://windowsitpro.com/powershell/break-your-batch-habit-and-move-
powershell>
>>
>>
>> <https://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx>
>>
> If using the OS services to kill a running blender instance seems
> drastic.
> 
> Maybe you can finesse it with some python scripting.
> <http://www.blender.org/api/blender_python_api_2_76_1/
bpy.app.handlers.html>
> 
> You'll still want a way to communicate.
> Maybe Jetty or Tomcat.
>
Seems heavy.

How about two user threads? One to process entries on a queue of blender 
requests and the other to monitor a socket for blender requests and 
action them [add/delete queue entries and, on request, kill the current 
blender process]. 

Question for the OP: it appears that any user can add blender tasks to 
the queue, but can any user kill the current blender task regardless of 
who submitted it? 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32844

On Friday, October 9, 2015 at 5:43:48 AM UTC-4, Martin Gregorie wrote:
> How about two user threads? One to process entries on a queue of blender 
> requests and the other to monitor a socket for blender requests and 
> action them [add/delete queue entries and, on request, kill the current 
> blender process]. 
> 
Currently it's just a render folder and an output folder.  Java checks the render folder on an infinite loop with a 30 second pause for new things to render one at a time, renames input when done so it doesn't get picked up again.  There is no queue.  If there are multiple files they're likely getting picked up alphabetically.  I just need to find the code to terminate a render process started from Java.

> Question for the OP: it appears that any user can add blender tasks to 
> the queue, but can any user kill the current blender task regardless of 
> who submitted it? 

Currently it is just one user submitting new blend files but allowing multiple users to submit and specifying who can terminate what could be something to consider.

[toc] | [prev] | [next] | [standalone]

#32849

On Fri, 09 Oct 2015 05:12:15 -0700, Eric Douglas wrote:

> On Friday, October 9, 2015 at 5:43:48 AM UTC-4, Martin Gregorie wrote:
>> How about two user threads? One to process entries on a queue of
>> blender requests and the other to monitor a socket for blender requests
>> and action them [add/delete queue entries and, on request, kill the
>> current blender process].
>> 
> Currently it's just a render folder and an output folder.  Java checks
> the render folder on an infinite loop with a 30 second pause for new
> things to render one at a time, renames input when done so it doesn't
> get picked up again.
>
Yes, I realised that you are using something like that.

> There is no queue.  If there are multiple files
> they're likely getting picked up alphabetically.
>
Conceptually thats a queue of waiting render jobs.

I was wondering if, given that you may need to build a client process to 
control the render process, if it might make sense for that to also be 
used to submit and/or remove files to be rendered. That might be better 
for the user(s) as there's only one tool to understand.

> I just need to find the code to terminate a render process started 
> from Java.
> 
Yes. Question for you: does the rendering program provide any way to stop 
it in mid-render apart from killing the process?

If it doesn't, a clean way to solve that would be something like the two 
thread Java server I suggested. One type of thread runs renderers via 
ProcessBuilder.start() class and can stop them via Process.destroy(). The 
other type accepts requests from users. 'Stop' requests causes it to 
remove a render request from the queue if it hasn't yet started or passes 
it to the render thread if the job is running. That thread can kill the 
current render process via Process.destroy() and start the next render 
job via ProcessBuilder.start().
 
>> Question for the OP: it appears that any user can add blender tasks to
>> the queue, but can any user kill the current blender task regardless of
>> who submitted it?
> 
> Currently it is just one user submitting new blend files but allowing
> multiple users to submit and specifying who can terminate what could be
> something to consider.
>
The rendering control server may be a bit easier to implement if, as Jeff 
suggested, each request has a ticket no. and the requests are managed by 
a Queue instance which stores pending requests until the render thread is 
ready for them.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#32854

On Friday, October 9, 2015 at 9:54:56 AM UTC-4, Martin Gregorie wrote:
> I was wondering if, given that you may need to build a client process to 
> control the render process, if it might make sense for that to also be 
> used to submit and/or remove files to be rendered. That might be better 
> for the user(s) as there's only one tool to understand.
> 
> > I just need to find the code to terminate a render process started 
> > from Java.
> > 
> Yes. Question for you: does the rendering program provide any way to stop 
> it in mid-render apart from killing the process?
> 
> If it doesn't, a clean way to solve that would be something like the two 
> thread Java server I suggested. One type of thread runs renderers via 
> ProcessBuilder.start() class and can stop them via Process.destroy(). The 
> other type accepts requests from users. 'Stop' requests causes it to 
> remove a render request from the queue if it hasn't yet started or passes 
> it to the render thread if the job is running. That thread can kill the 
> current render process via Process.destroy() and start the next render 
> job via ProcessBuilder.start().
>  
Java is starting the render using ProcessBuilder which executes Blender.exe and passes it a python script which has the actual render command which starts a second Blender.exe task.  I tried Process.destroy() and it killed the first task and left the second Blender process running, though these two tasks must be communicating because we do redirect the output from the task ProcessBuilder started and it is logging every step.  It appears Blender doesn't provide a kill command, so the only way I can see so far to end this task is to use a Java command or Windows tool that can get a list of all running processes and search for Blender.

> >> Question for the OP: it appears that any user can add blender tasks to
> >> the queue, but can any user kill the current blender task regardless of
> >> who submitted it?
> > 
> > Currently it is just one user submitting new blend files but allowing
> > multiple users to submit and specifying who can terminate what could be
> > something to consider.
> >
> The rendering control server may be a bit easier to implement if, as Jeff 
> suggested, each request has a ticket no. and the requests are managed by 
> a Queue instance which stores pending requests until the render thread is 
> ready for them.

That does seem like a good idea for later enhancement, once I get a remote access tool able to abort a render, to use that tool to start renders instead of the current procedure to drop blend files into a folder.  Then they can set the order they want things to render, and I can show the progress of the current task.

[toc] | [prev] | [next] | [standalone]

#32857

On 10/09/2015 12:08 PM, Eric Douglas wrote:

What could be the best way to rewrite this?  We need this to be a 
background process which allows a user to remotely cancel the render 
from their pc.  I could do this with a Java program, or is there a 
scripting version that makes sense?

There is no best way because the requirements keep changing.

>>
> Java is starting the render using ProcessBuilder which executes Blender.exe and passes it a python script which has the actual render command which starts a second Blender.exe task.  I tried Process.destroy() and it killed the first task and left the second Blender process running, though these two tasks must be communicating because we do redirect the output from the task ProcessBuilder started and it is logging every step.  It appears Blender doesn't provide a kill command, so the only way I can see so far to end this task is to use a Java command or Windows tool that can get a list of all running processes and search for Blender.
>

[toc] | [prev] | [next] | [standalone]

#32858

On 10/09/2015 12:43 PM, Jeff Higgins wrote:
> On 10/09/2015 12:08 PM, Eric Douglas wrote:
>
> What could be the best way to rewrite this?  We need this to be a
> background process which allows a user to remotely cancel the render
> from their pc.  I could do this with a Java program, or is there a
> scripting version that makes sense?
>
> There is no best way because the requirements keep changing.
>
>>>
>> Java is starting the render using ProcessBuilder which executes
>> Blender.exe and passes it a python script which has the actual render
>> command which starts a second Blender.exe task.  I tried
>> Process.destroy() and it killed the first task and left the second
>> Blender process running, though these two tasks must be communicating
>> because we do redirect the output from the task ProcessBuilder started
>> and it is logging every step.  It appears Blender doesn't provide a
>> kill command, so the only way I can see so far to end this task is to
>> use a Java command or Windows tool that can get a list of all running
>> processes and search for Blender.
>>
>
<https://github.com/pbattaglia/blendertools/blob/master/src/render_runner.py>

[toc] | [prev] | [next] | [standalone]

#32855

Eric Douglas schrieb:
> Currently it's just a render folder and an output folder.
 > Java checks the render folder on an infinite loop with a
 > 30 second pause for new things to render one at a time,
 > renames input when done so it doesn't get picked up again.
 > There is no queue.  If there are multiple files they're likely
 > getting picked up alphabetically.  I just need to find the
 > code to terminate a render process started from Java.

kill -9 xx
https://en.wikipedia.org/wiki/Kill_%28command%29

[toc] | [prev] | [next] | [standalone]

#32856

http://docs.oracle.com/javase/7/docs/api/java/lang/Process.html
destroy
public abstract void destroy()
Kills the subprocess. The subprocess represented by
this Process object is forcibly terminated.


Jan Burse schrieb:
> Eric Douglas schrieb:
>> Currently it's just a render folder and an output folder.
>  > Java checks the render folder on an infinite loop with a
>  > 30 second pause for new things to render one at a time,
>  > renames input when done so it doesn't get picked up again.
>  > There is no queue.  If there are multiple files they're likely
>  > getting picked up alphabetically.  I just need to find the
>  > code to terminate a render process started from Java.
>
> kill -9 xx
> https://en.wikipedia.org/wiki/Kill_%28command%29

[toc] | [prev] | [next] | [standalone]

#32860

On Friday, October 9, 2015 at 12:30:19 PM UTC-4, Jan Burse wrote:
> http://docs.oracle.com/javase/7/docs/api/java/lang/Process.html
> destroy
> public abstract void destroy()
> Kills the subprocess. The subprocess represented by
> this Process object is forcibly terminated.

I tried the destroy method, it didn't work.  The java ProcessBuilder starts command Blender.exe with a -P that passes it a python script.  This line in the script apparently starts a second Blender.exe which actually does the rendering.  Only the first Blender task is destroyed.
bpy.ops.render.render( write_still=True )

If this Java process is started from a cmd.exe window and we press ctrl + break on that window it does terminate the render.  This is what I hoped to emulate through code.  This ctrl + break command can only be executed at the server's physical console.  We cannot even sign in remotely to this server, it breaks the Blender program.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web