Do you foresee any issues with use all available CPU cores when used on a
shared resource like CI server?
When writing guidelines for my customers' devs I'm always very firm on that
build jobs are not allowed to fork (or similar) freely and thereby
occupy more than their share of the resources on
2015-01-12 9:03 GMT+01:00 Anders Hammar and...@hammar.net:
Do you foresee any issues with use all available CPU cores when used on a
shared resource like CI server?
When writing guidelines for my customers' devs I'm always very firm on that
build jobs are not allowed to fork (or similar)
Kristian, we tested only spinning media.
I think this test was done in 2010 or 2011.
We did not have SSD that time.
In build system I would still rather rely on spinning media.
Yes, right, constructing ButeBuffer every time is just bad idea. Since they
are not thread-safe, they should be stored
On Monday, 12 January 2015, Anders Hammar and...@hammar.net wrote:
Do you foresee any issues with use all available CPU cores when used on a
shared resource like CI server?
When writing guidelines for my customers' devs I'm always very firm on that
build jobs are not allowed to fork (or
TL;DR we should let the OS be responsible for applying resource limits, we
should use every resource we are given to the full in order to reduce the
build time as that shortens the feedback loop and makes developers mire
productive
I guess I agree. Guidelines doesn't work anyways as the
2015-01-12 9:24 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com:
Creating a 256MB zip file with typical jar content has a compression
phase of 4 seconds on my 6 core machine, with 1.4 seconds in the
gather phase. You'd need some really huge zips for this to become a
real problem,
I guess every virtual machine might be configured to use only few CPU out of
let's say 16 CPU.
I am convinced use all available CPU cores means application Threads and
not the CPU itself.
The customer should be convinced we don't make any selection on particular
processors.
Of course Java program
https://github.com/apache/commons-compress/blob/trunk/src/main/java/org/apache/commons/compress/archivers/zip/ParallelScatterZipCreator.java#L84
I'm looking at using a PriorityQueue for scheduling the tasks so the
largest files get zipped first. Combined with ForkJoinPool work
stealing I'm hoping
I do not really doubt your numbers, Tibor. But I think there's a huge
difference between real world application benchmarks and just
measuring what can be done in a constructed test case. Both are of
course valuable, but they have somewhat different applicability. And I
think SSD's make a huge
GitHub user Enygma2002 opened a pull request:
https://github.com/apache/maven-indexer/pull/9
Indexing a repository with the indexer-cli (using -i and -r parameters)
creates an empty packed index.
Caused by the fact that the IndexSearcher obtained before indexer.scan() is
called is
400MB/s is way faster than any single spinning disk can do and actually
quite a bit faster than SATA I/II max speeds [1]. This suggests the data
was written to the operating system caches but never made it to the disk
physical media. That is, unless you had a RAID connected to system using
some
The Apache Maven team is pleased to announce the release of the
Apache Maven WAR Plugin, version 2.6
The WAR Plugin is responsible for collecting all artifact dependencies, classes
and resources of the web application and packaging them into a web application
archive.
Hi Karl,
I added a feature at gpg and bug fixes at wagon-ssh
Very much appreciated when ever you can release them
Thanks
-D
Hi,
We solved 11 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11134version=20572
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MEJB%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
Staging
Hi,
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11431version=20125
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MGPG%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
Staging
GitHub user Enygma2002 opened a pull request:
https://github.com/apache/maven-indexer/pull/11
Add minimal information to a newly created artifact info (using the
IndexUtils method), linking it to the context it belongs to.
While trying to write an IndexCreator, I`ve discovered that
yes it goes to OS with one exception, I was trying to explain :)
The exception is that file system is mapped with memory, and so the writes
go to the memory fast, but they go to the file system as well however
slowly. The trick is that the data goes to both memory and IO, they can be
read
Github user Enygma2002 closed the pull request at:
https://github.com/apache/maven-indexer/pull/9
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
GitHub user Enygma2002 opened a pull request:
https://github.com/apache/maven-indexer/pull/10
Indexing a repository with the indexer-cli (using -i and -r parameters)
creates an empty packed index.
Caused by the fact that the IndexSearcher obtained before indexer.scan() is
called
Github user Enygma2002 commented on the pull request:
https://github.com/apache/maven-indexer/pull/9#issuecomment-69610327
Please see #10 instead, since I`ve initially made the changes on my fork's
master branch.
---
If your project is set up for it, you can reply to this email and
20 matches
Mail list logo
