Re: Question about xmlrpc

[Brian Foster]

You have to be careful with the number you set that too because you are 
basically telling XML-RPC that it is now allowed to create 2000 threads in the 
same JVM... not a good practice... I don't remember the exact number but the 
JVM will crash if it creates a certain number of threads because there is a 
limit to the number of threads one process can create and I believe this is 
restricted at the operating system level... and i believe this number is less 
than 2000... The trunk filemgr and wengine already have built-in client retry 
handling support and are configurable via java properties (i.e. 
org.apache.oodt.cas.filemgr.system.xmlrpc.connection.retries and 
o.a.o.c.filemger.system.connection.retry.interval.seconds and there are similar 
ones for wengine)... The message you are seeing is XML-RPC server logging that 
it already using a 100 worker threads... you will see this message if you 
create a 100+ jobs in the RM (e.g. Workflow Conditions and Tasks) and they all 
start talking to the workflow manager or file manger at the same time... the 
client retry handlers will catch this error and just wait and retry again... 
you shouldn't be loosing any data... the only inconvenience I guess is that 
message is cluttering the logs

-Brian

On Feb 15, 2012, at 10:42 PM, "Cheng, Cecilia S (388K)" 
 wrote:

> 
> Hi Chris,
> 
> Sure we can discuss this in dev@oodt.apache.org.
> 
> If you feel comfortable w/ the 2000 number, of course I can push the patch
> upstream into Apache OODT. But what kind of tests, if any, should we do
> before we deliver the patch? Our projects are concerned that if we
> arbitrarily set a number, we don't know what other problems it might cause.
> 
> Thanks,
> Cecilia
> 
> On 2/15/12 10:07 PM, "Mattmann, Chris A (388J)"
>  wrote:
> 
>> Hi Cecilia,
>> 
>> This is really good news!
>> 
>> A couple questions:
>> 
>> 1. Do you think you would be willing to push your XML-RPC patches upstream
>> into Apache OODT so others in the
>> community could benefit? This would involve filing corresponding JIRA 
>> issue(s)
>> [1], and then letting the dev@oodt.apache.org
>> know.
>> 
>> 2. Can we move this conversation onto dev@oodt.apache.org? I think others
>> could benefit from the answers below.
>> 
>> Thanks and let me know. If you'd like to discuss more, that's fine too, but
>> I'd urge us to move this onto the public Apache OODT
>> lists. 
>> 
>> Cheers,
>> Chris
>> 
>> [1] http://issues.apache.org/jira/browse/OODT
>> 
>> On Feb 15, 2012, at 2:31 PM, Cheng, Cecilia S (388K) wrote:
>> 
>>> Hi Chris and Paul,
>>> 
>>> Just want to fill you in on where we are w/ the xmlrpc problem that we see 
>>> on
>>> ACOS and PEATE and get your advice.
>>> 
>>> As you might recall, on both projects, and in all 3 components (FM, RM, and
>>> WEngine), we will periodically see the following message in the console:
>>> 
>>> java.lang.RuntimeException: System overload: Maximum number of concurrent
>>> requests (100) exceeded
>>> 
>>> when the system is very busy. Since upgrading to the newer version of xmlrpc
>>> seems to be quite involved, we thought that we will just download the source
>>> code and change the hardcoded number of 100 to something bigger, recompile
>>> the jar file and use that in our system.
>>> 
>>> So I set the number to 2000 and have Lan, Michael and Irina try again. All 3
>>> of them said that it solved their problems, but now that this works, we have
>>> other concerns:
>>> 
>>> [1] Will setting this number so high (2000 vs. 100)  create other problems?
>>> [2] How can we find out what is a “good” number to use?
>>> [3] What are some ways I can monitor these concurrent requests as they run?
>>> netstat?
>>> 
>>> Would you please share your thought on this?
>>> 
>>> Thanks,
>>> Cecilia
>>> 
>> 
>> 
>> ++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattm...@nasa.gov
>> WWW:   http://sunset.usc.edu/~mattmann/
>> Phone: +1 (818) 354-8810
>> ++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++
>> 
> 

Build failed in Jenkins: oodt-trunk #265

[Apache Jenkins Server]

See 

Changes:

[luca] Removed blank line to test SVN write access

--
[...truncated 1408 lines...]
[JENKINS] Archiving 

 to 
/home/hudson/hudson/jobs/oodt-trunk/modules/org.apache.oodt$cas-resource/builds/2012-02-16_12-36-11/archive/org.apache.oodt/cas-resource/0.4-SNAPSHOT/cas-resource-0.4-SNAPSHOT-dist.zip
[INFO] 
[INFO] Building Catalog and Archive Workflow Management Component
[INFO]task-segment: [install]
[INFO] 
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 25 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 1 source file to 

[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory: 


---
 T E S T S
---
Running org.apache.oodt.cas.workflow.cli.TestWorkflowCli
Tests run: 20, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.113 sec
Running 
org.apache.oodt.cas.workflow.instrepo.TestLuceneWorkflowInstanceRepository
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.307 sec
Running org.apache.oodt.cas.workflow.structs.TestHighestFIFOPrioritySorter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec
Running org.apache.oodt.cas.workflow.system.TestXmlRpcWorkflowManager
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.87 sec
Running org.apache.oodt.cas.workflow.system.TestXmlRpcWorkflowManagerClient
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.268 sec
Running org.apache.oodt.cas.workflow.repository.TestPackagedWorkflowRepository
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.989 sec
Running org.apache.oodt.cas.workflow.repository.TestWorkflowDataSourceRepository
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.338 sec
Running org.apache.oodt.cas.workflow.structs.TestFILOPrioritySorter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.oodt.cas.workflow.tools.TestInstanceRepoCleaner
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.472 sec
Running org.apache.oodt.cas.workflow.structs.TestHighestPrioritySorter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.oodt.cas.workflow.examples.TestExternScriptTaskInstance
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
Running org.apache.oodt.cas.workflow.util.TestGenericWorkflowObjectFactory
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
Running org.apache.oodt.cas.workflow.engine.TestThreadPoolWorkflowEngine
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.05 sec
Running org.apache.oodt.cas.workflow.repository.TestWorkflowRepository
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.069 sec

Results :

Tests run: 53, Failures: 0, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: 

[INFO] Preparing javadoc:javadoc
[WARNING] Removing: javadoc from forked lifecycle, to prevent recursive 
invocation.
[INFO] No goals needed for project - skipping
[WARNING] DEPRECATED [aggregate]: since 2.5. Use the goals 
javadoc:aggregate and javadoc:test-aggregate instead.
[INFO] [javadoc:javadoc {execution: attach-javadocs}]
[INFO] [assembly:single {execution: default}]
[INFO] Reading assembly descriptor: src/main/assembly/assembly.xml
[INFO] Processing DependencySet (output=lib)
[INFO] Building tar : 

[INFO] Processing DependencySet (output=lib)
[INFO] Building zip: 

[INFO] [install:install {execution: default-install}]
[INFO] Installing 

build fail ?

[Cinquini, Luca (3880)]

Hi all,
I have a question about the OODT build...

I tried my first commit by removing a blank line in an XML file in the 
"opendap-ps" module, and apparently this caused the build to fail with this 
error message:


[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to create assembly: Failed to retrieve OS environment variables. 
Reason: Cannot run program "env": java.io.IOException: error=24, Too many open 
files

[INFO] 
[INFO] For more information, run Maven with the -e switch

Did I do something wrong, or is there something that needs fixing on the server 
?

See: https://builds.apache.org/job/oodt-trunk/265/

thanks, Luca

Re: build fail ?

[Sean Kelly]

> [INFO] Failed to create assembly: Failed to retrieve OS environment 
> variables. Reason: Cannot run program "env": java.io.IOException: error=24, 
> Too many open files
> ...
> Did I do something wrong, or is there something that needs fixing on the 
> server ?

Sounds like a server issue.

Jenkins may need to be restarted on the server, or perhaps the server itself 
needs a reboot.

Or, optimistically, you might just try re-kicking the build off manually and 
see if it works.

--k

Re: build fail ?

[Cinquini, Luca (3880)]

Thanks Sean - looks like "Jenkins is going to shut down" so someone is probably 
restarting it.
I just wanted to check with people more knowledgeable than myself, since I'm 
new to this.
thanks, Luca

On Feb 16, 2012, at 7:46 AM, Sean Kelly wrote:

>> [INFO] Failed to create assembly: Failed to retrieve OS environment 
>> variables. Reason: Cannot run program "env": java.io.IOException: error=24, 
>> Too many open files
>> ...
>> Did I do something wrong, or is there something that needs fixing on the 
>> server ?
> 
> Sounds like a server issue.
> 
> Jenkins may need to be restarted on the server, or perhaps the server itself 
> needs a reboot.
> 
> Or, optimistically, you might just try re-kicking the build off manually and 
> see if it works.
> 
> --k
> 

Re: build fail ?

[Mattmann, Chris A (388J)]

Yep +1 I was going to suggest the same thing, SK.

Luca: you can subscribe to bui...@apache.org and chat
with the build folks about Jenkins there. I'm on the list and from 
time to time send them messages about the auto build. I'd chalk
this one up to the Jenkins slave it ran on having too many open files
or something.

Cheers,
Chris

On Feb 16, 2012, at 6:46 AM, Sean Kelly wrote:

>> [INFO] Failed to create assembly: Failed to retrieve OS environment 
>> variables. Reason: Cannot run program "env": java.io.IOException: error=24, 
>> Too many open files
>> ...
>> Did I do something wrong, or is there something that needs fixing on the 
>> server ?
> 
> Sounds like a server issue.
> 
> Jenkins may need to be restarted on the server, or perhaps the server itself 
> needs a reboot.
> 
> Or, optimistically, you might just try re-kicking the build off manually and 
> see if it works.
> 
> --k
> 


++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++

Re: Question about xmlrpc

[Mattmann, Chris A (388J)]

Hi Cecilia,

Awesome I'll bring the conversation on list shortly (next few hours) and reply
to the below questions there.

Cheers,
Chris

On Feb 15, 2012, at 10:42 PM, Cheng, Cecilia S (388K) wrote:

> 
> Hi Chris,
> 
> Sure we can discuss this in dev@oodt.apache.org.
> 
> If you feel comfortable w/ the 2000 number, of course I can push the patch
> upstream into Apache OODT. But what kind of tests, if any, should we do
> before we deliver the patch? Our projects are concerned that if we
> arbitrarily set a number, we don't know what other problems it might cause.
> 
> Thanks,
> Cecilia
> 
> On 2/15/12 10:07 PM, "Mattmann, Chris A (388J)"
>  wrote:
> 
>> Hi Cecilia,
>> 
>> This is really good news!
>> 
>> A couple questions:
>> 
>> 1. Do you think you would be willing to push your XML-RPC patches upstream
>> into Apache OODT so others in the
>> community could benefit? This would involve filing corresponding JIRA 
>> issue(s)
>> [1], and then letting the dev@oodt.apache.org
>> know.
>> 
>> 2. Can we move this conversation onto dev@oodt.apache.org? I think others
>> could benefit from the answers below.
>> 
>> Thanks and let me know. If you'd like to discuss more, that's fine too, but
>> I'd urge us to move this onto the public Apache OODT
>> lists. 
>> 
>> Cheers,
>> Chris
>> 
>> [1] http://issues.apache.org/jira/browse/OODT
>> 
>> On Feb 15, 2012, at 2:31 PM, Cheng, Cecilia S (388K) wrote:
>> 
>>> Hi Chris and Paul,
>>> 
>>> Just want to fill you in on where we are w/ the xmlrpc problem that we see 
>>> on
>>> ACOS and PEATE and get your advice.
>>> 
>>> As you might recall, on both projects, and in all 3 components (FM, RM, and
>>> WEngine), we will periodically see the following message in the console:
>>> 
>>> java.lang.RuntimeException: System overload: Maximum number of concurrent
>>> requests (100) exceeded
>>> 
>>> when the system is very busy. Since upgrading to the newer version of xmlrpc
>>> seems to be quite involved, we thought that we will just download the source
>>> code and change the hardcoded number of 100 to something bigger, recompile
>>> the jar file and use that in our system.
>>> 
>>> So I set the number to 2000 and have Lan, Michael and Irina try again. All 3
>>> of them said that it solved their problems, but now that this works, we have
>>> other concerns:
>>> 
>>> [1] Will setting this number so high (2000 vs. 100)  create other problems?
>>> [2] How can we find out what is a “good” number to use?
>>> [3] What are some ways I can monitor these concurrent requests as they run?
>>> netstat?
>>> 
>>> Would you please share your thought on this?
>>> 
>>> Thanks,
>>> Cecilia
>>> 
>> 
>> 
>> ++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattm...@nasa.gov
>> WWW:   http://sunset.usc.edu/~mattmann/
>> Phone: +1 (818) 354-8810
>> ++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++
>> 
> 


++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++

Re: Question about xmlrpc

[Mattmann, Chris A (388J)]

Hi Cecilia,

Oops, I didn't even realize you brought this on list.

Awesome, here we go then, happy to reply :) I just wanted
others in the community to benefit from the answers.

So, here we go. Some background folks: ACOS and OCO2
and NPP Sounder PEATE have been seeing some interesting issues
with the XML-RPC connection pool under heavy process, ingest, and 
resource manager load. This is due to an old version of the XML-RPC
library we are using (2.0.1) and its hard coded thread limitation of 100
threads. 

In certain projects, we've seen them address this by adding more file managers
or workflow managers, and running them on multiple ports and scaling out
horizontally that way. Cecilia's projects, however, decided to take the 
initiative and modify the XML-RPC library to up the thread limit to 2000.

I suggested that Cecilia, in response to her questions below if this is
a good number or not, bring this conversation on list, so that others could
benefit, so here we are.

OK, so my thought on this is the following:

1. file a JIRA issue to make XML-RPC thread limit in FM, WM and RM (and 
crawler and pushpull) take a config property, akin to the other XML-RPC
config properties, e.g., in file manager, etc. We could call it:

org.apache.oodt.cas.[filemgr|workflow|resmgr|crawler|pushpull].xmlrpc.maxThreads

2. We could pass this in via the *.properties files for the file manager, 
workflow manager,
resource manager, crawler and push pull as a system property the same way we 
have other configs for those servers

This way the property is configurable. A sensible default value is 256, as this 
will 
have a lot to do (as the value is raised) with sysadmins who have the ability 
to increase
the default ulimit. In addition, whether you are on Windows or Linux, the cost 
of creating
a thread compared to a process is significantly different, so high values of 
this may affect
the target deployment environment. We shouldn't set it in the upstream core 
Apache OODT
services to be much larger (by default) than 256, but then in downstream 
projects they can
configure it however they want.

3. the patch in #1 should simply include only the portions of the XML-RPC 
library that required
modification, and they should probably live in parallel to the 
src/main/java/org/apache/oodt 
tree (perhaps in src/main/java/org/apache/xmlrpc).

Thoughts?

Cheers,
Chris

On Feb 15, 2012, at 10:42 PM, Cheng, Cecilia S (388K) wrote:

> 
> Hi Chris,
> 
> Sure we can discuss this in dev@oodt.apache.org.
> 
> If you feel comfortable w/ the 2000 number, of course I can push the patch
> upstream into Apache OODT. But what kind of tests, if any, should we do
> before we deliver the patch? Our projects are concerned that if we
> arbitrarily set a number, we don't know what other problems it might cause.
> 
> Thanks,
> Cecilia
> 
> On 2/15/12 10:07 PM, "Mattmann, Chris A (388J)"
>  wrote:
> 
>> Hi Cecilia,
>> 
>> This is really good news!
>> 
>> A couple questions:
>> 
>> 1. Do you think you would be willing to push your XML-RPC patches upstream
>> into Apache OODT so others in the
>> community could benefit? This would involve filing corresponding JIRA 
>> issue(s)
>> [1], and then letting the dev@oodt.apache.org
>> know.
>> 
>> 2. Can we move this conversation onto dev@oodt.apache.org? I think others
>> could benefit from the answers below.
>> 
>> Thanks and let me know. If you'd like to discuss more, that's fine too, but
>> I'd urge us to move this onto the public Apache OODT
>> lists. 
>> 
>> Cheers,
>> Chris
>> 
>> [1] http://issues.apache.org/jira/browse/OODT
>> 
>> On Feb 15, 2012, at 2:31 PM, Cheng, Cecilia S (388K) wrote:
>> 
>>> Hi Chris and Paul,
>>> 
>>> Just want to fill you in on where we are w/ the xmlrpc problem that we see 
>>> on
>>> ACOS and PEATE and get your advice.
>>> 
>>> As you might recall, on both projects, and in all 3 components (FM, RM, and
>>> WEngine), we will periodically see the following message in the console:
>>> 
>>> java.lang.RuntimeException: System overload: Maximum number of concurrent
>>> requests (100) exceeded
>>> 
>>> when the system is very busy. Since upgrading to the newer version of xmlrpc
>>> seems to be quite involved, we thought that we will just download the source
>>> code and change the hardcoded number of 100 to something bigger, recompile
>>> the jar file and use that in our system.
>>> 
>>> So I set the number to 2000 and have Lan, Michael and Irina try again. All 3
>>> of them said that it solved their problems, but now that this works, we have
>>> other concerns:
>>> 
>>> [1] Will setting this number so high (2000 vs. 100)  create other problems?
>>> [2] How can we find out what is a “good” number to use?
>>> [3] What are some ways I can monitor these concurrent requests as they run?
>>> netstat?
>>> 
>>> Would you please share your thought on this?
>>> 
>>> Thanks,
>>> Cecilia
>>> 
>> 
>> 
>> ++
>> Chris Mattmann, Ph.D.
>

Re: build fail ?

[Cinquini, Luca (3880)]

Thanks Chris, I followed your suggestion and inquired if there's anything that 
can be done about these failures...
I'll forward whatever the build people say...
Luca

On Feb 16, 2012, at 8:47 AM, Mattmann, Chris A (388J) wrote:

> Yep +1 I was going to suggest the same thing, SK.
> 
> Luca: you can subscribe to bui...@apache.org and chat
> with the build folks about Jenkins there. I'm on the list and from 
> time to time send them messages about the auto build. I'd chalk
> this one up to the Jenkins slave it ran on having too many open files
> or something.
> 
> Cheers,
> Chris
> 
> On Feb 16, 2012, at 6:46 AM, Sean Kelly wrote:
> 
>>> [INFO] Failed to create assembly: Failed to retrieve OS environment 
>>> variables. Reason: Cannot run program "env": java.io.IOException: error=24, 
>>> Too many open files
>>> ...
>>> Did I do something wrong, or is there something that needs fixing on the 
>>> server ?
>> 
>> Sounds like a server issue.
>> 
>> Jenkins may need to be restarted on the server, or perhaps the server itself 
>> needs a reboot.
>> 
>> Or, optimistically, you might just try re-kicking the build off manually and 
>> see if it works.
>> 
>> --k
>> 
> 
> 
> ++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattm...@nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
> 

Re: build fail ?

[Mattmann, Chris A (388J)]

Thanks Luca.

My guess is that Maven and/or the OODT tests (which all call "env" underneath 
via Java and its Process/System call framework) simply ran out of open files
from making those forked calls.

A lot of times that's simply build machine related, and not something related
to the tests. The best bet to do is what Sean K. suggested, and if you think 
you 
broke something (which in this case, I'm sure you didn't), then simply try 
rerunning
again and see if Jenkins gives you another build slave to run on. If all is 
well, 
then we're probably fine...

Cheers,
Chris

On Feb 16, 2012, at 11:26 AM, Cinquini, Luca (3880) wrote:

> Thanks Chris, I followed your suggestion and inquired if there's anything 
> that can be done about these failures...
> I'll forward whatever the build people say...
> Luca
> 
> On Feb 16, 2012, at 8:47 AM, Mattmann, Chris A (388J) wrote:
> 
>> Yep +1 I was going to suggest the same thing, SK.
>> 
>> Luca: you can subscribe to bui...@apache.org and chat
>> with the build folks about Jenkins there. I'm on the list and from 
>> time to time send them messages about the auto build. I'd chalk
>> this one up to the Jenkins slave it ran on having too many open files
>> or something.
>> 
>> Cheers,
>> Chris
>> 
>> On Feb 16, 2012, at 6:46 AM, Sean Kelly wrote:
>> 
 [INFO] Failed to create assembly: Failed to retrieve OS environment 
 variables. Reason: Cannot run program "env": java.io.IOException: 
 error=24, Too many open files
 ...
 Did I do something wrong, or is there something that needs fixing on the 
 server ?
>>> 
>>> Sounds like a server issue.
>>> 
>>> Jenkins may need to be restarted on the server, or perhaps the server 
>>> itself needs a reboot.
>>> 
>>> Or, optimistically, you might just try re-kicking the build off manually 
>>> and see if it works.
>>> 
>>> --k
>>> 
>> 
>> 
>> ++
>> Chris Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattm...@nasa.gov
>> WWW:   http://sunset.usc.edu/~mattmann/
>> ++
>> Adjunct Assistant Professor, Computer Science Department
>> University of Southern California, Los Angeles, CA 90089 USA
>> ++
>> 
> 


++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++

Jenkins build is back to normal : oodt-trunk #266

[Apache Jenkins Server]

See 

Re: [jira] [Created] (OODT-380) Pypes UX

[Cameron Goodale]

Adam,

I am digging this tool, especially since right now I am in working in SNOW
workflow heaven and i think a visual tool would really help everyone see
what is happening in the pipeline.

The License is ALv2 so that is a good start, and it is written in Python ;)

I would be up for throwing a couple hours at trying to set it up and
install in on my machine and test it out.

-Cam

On Wed, Feb 15, 2012 at 5:01 PM, Adam Estrada (Created) (JIRA) <
j...@apache.org> wrote:

> Pypes UX
> 
>
> Key: OODT-380
> URL: https://issues.apache.org/jira/browse/OODT-380
> Project: OODT
>  Issue Type: New Feature
>  Components: website
>Affects Versions: 0.3
> Environment: All
>Reporter: Adam Estrada
>Priority: Minor
> Fix For: 0.4
>
>
> What would you think about integrating http://www.pypes.org/ as the UI
> for the workflow manager? Seems like a decent idea as most of OODT is about
> building workflows, right?
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators:
> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

Re: Licensing question concerning jQuery use

[Resneck, Gabriel M (388J)]

Hey, guys.  It’s been a while and I haven’t seen a response.
Does anyone have an idea of how I should handle this?
Thanks!

Gabe =)


On 2/1/12 4:08 PM, "resneck"  wrote:

Hi, all.
I’m currently working on get the cas-browser (a module that works with Balance) 
ready to submit for out project.  There’s no patch or issue yet, but don’t 
worry, they’re coming. The cas-browser uses jQuery (a 3rd party library at 
jquery.org) for much of its functionality.  Jquery can use the MIT and GPL 
licenses (http://jquery.org/license).  Which license should I use?  Do I need 
to include a header for either of these licenses, and, if so, where would I 
find these headers and I which files would I have to include them?  Only in the 
jQuery libraries that we include in cas-browser or in all cas-browser files 
that use jQuery?
Thanks!

Gabe Resneck =)

Re: Licensing question concerning jQuery use

[Mattmann, Chris A (388J)]

Hi Gabe,

I already replied to you on this earlier:

http://s.apache.org/6ol

Did you see it? 

Anyways I saw LEGAL-126 [1] where Sam basically affirmed my 
thoughts so I think we're fine.

Cheers,
Chris

[1] https://issues.apache.org/jira/browse/LEGAL-126

On Feb 16, 2012, at 3:36 PM, Resneck, Gabriel M (388J) wrote:

> Hey, guys.  It’s been a while and I haven’t seen a response.
> Does anyone have an idea of how I should handle this?
> Thanks!
> 
> Gabe =)
> 
> 
> On 2/1/12 4:08 PM, "resneck"  wrote:
> 
> Hi, all.
> I’m currently working on get the cas-browser (a module that works with 
> Balance) ready to submit for out project.  There’s no patch or issue yet, but 
> don’t worry, they’re coming. The cas-browser uses jQuery (a 3rd party library 
> at jquery.org) for much of its functionality.  Jquery can use the MIT and GPL 
> licenses (http://jquery.org/license).  Which license should I use?  Do I need 
> to include a header for either of these licenses, and, if so, where would I 
> find these headers and I which files would I have to include them?  Only in 
> the jQuery libraries that we include in cas-browser or in all cas-browser 
> files that use jQuery?
> Thanks!
> 
> Gabe Resneck =)


++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattm...@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++