[Design of JBoss jBPM] - Invalid JSF-Console release
by thomas.diesler＠jboss.com
Folks,
the jbpm-3.2.6 build fails because it references a jsf-console that is not released
| <jbpm.jsf-console.version>3.2.6.GA</jbpm.jsf-console.version>
|
| [tdiesler@tddell jbpm3]$ ls -1 jsf-console
| 3.2.2.GA
| 3.3.0.GA
| 3.3.1.GA
|
There is a tag for jsf-console-3.2.6.GA but it actually has a different version and references a 3.3.1-SNAPSHOT which is not used any more
| [tdiesler@tddell jsf-console-3.2.6.GA]$ find . -name pom.xml | xargs grep SNAPSHOT
| ./pom.xml: <version>3.3.1-SNAPSHOT</version>
| ./pom.xml: <jbpm.version>3.3.1-SNAPSHOT</jbpm.version>
| ./console/pom.xml: <version>3.3.1-SNAPSHOT</version>
| ./jbpm4jsf/pom.xml: <version>3.3.1-SNAPSHOT</version>
| ./soa/pom.xml: <version>3.3.1-SNAPSHOT</version>
|
The hudson box has been hacked to to contain that version. Why?
| [hudson@jbpm ~]$ ls -1 ~/.m2/repository/org/jbpm/jbpm3/jsf-console
| 3.2.6.GA
| 3.3.0.GA
| 3.3.1.GA
| 3.3.1-SNAPSHOT
|
All of this is happening at a point of time were we are trying to wrap up a release.
Can you please explain what is going on and why do see these unsolicited changes in the first place.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214395#4214395
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214395
17 years
[Design of Messaging on JBoss (Messaging/JBoss)] - ByteBuffer.allocateDirect ridiculously
by clebert.suconic＠jboss.com
I just found out ByteBuffer.allocateDirect is ridiculously slow, that's why the Buffer reuse on Journal made a lot of difference on the performance for us.
| final int TIMES = 50;
|
| final long numberOfIteractions = 1000000;
|
|
| public void testJustAllocateBufferDirect() throws Exception
| {
|
| long start = System.currentTimeMillis();
|
| for (int c = 0; c < TIMES; c++)
| {
| for (long i = 0; i < numberOfIteractions; i++)
| {
| if (i == 10000)
| {
| start = System.currentTimeMillis();
| }
| MessagingBuffer bufferSend = ChannelBuffers.wrappedBuffer(ByteBuffer.allocateDirect(1024));
|
| bufferSend.writeBytes(new byte[1024]);
| }
|
| long spentTime = System.currentTimeMillis() - start;
|
| System.out.println("Time BuffersDirect = " + spentTime);
| }
|
| }
|
| public void testOurBuffers() throws Exception
| {
|
| long start = System.currentTimeMillis();
|
| for (int c = 0; c < TIMES; c++)
| {
| for (long i = 0; i < numberOfIteractions; i++)
| {
| if (i == 10000)
| {
| start = System.currentTimeMillis();
| }
| ChannelBuffer bufferSend = ChannelBuffers.wrappedBuffer(AsynchronousFileImpl.newNativeBuffer(1024));
|
| bufferSend.writeBytes(new byte[1024]);
|
| AsynchronousFileImpl.destroyBuffer(bufferSend.toByteBuffer());
| }
|
| long spentTime = System.currentTimeMillis() - start;
|
| System.out.println("Time JBM JNI Buffers = " + spentTime);
| }
|
|
On the Above test, ByteBuffer.allocateDirect needed 100 seconds to complete the 1 million buffers.
While our code, allocating ByteBuffers directly through JNI, needed 2 seconds to complete 1 million buffers.
That *is* ridiculous.
The new Buffers were slicing the direct ByteBuffer, what affected the capacity, breaking buffer reuse, what raised this issue to my eyes.
I have made a few changes on the Journal, where we will allocate buffers directly, and I could get very good numbers with some simple tests. (Even thought I was not targeting any optimizations.. just looking after this bug on ByteBuffer).
We can talk about this tomorrow on the meeting.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214338#4214338
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214338
17 years