Clebert Suconic 's Blog

Pointers in JNI / C++

2010-05-14T14:56:00.000-07:00

When writing native code for Java (JNI), It's a common behaviour to store the pointer as long in a field in Java, and do a type-cast conversion on the native code back to the original pointer.

I did that on the native module on HornetQ, however this seems to eventually fail.

when using different bit sets as the target compilation (32 bits for instance) this seems to fail when you move back and forth.

The best way for that would be to use a Native Byte Buffer. This way you don't need to worry about conversions. You can just use a pointer back and forth:

Example:

In your Java class, you create this signature:

public class SomeClass
{
public native ByteBuffer initPointer();
}

And in your C++ code:

JNIEXPORT jobject JNICALL Java_SomeClass_initPointer
(JNIEnv * env, jobject obj)
{
return env->NewDirectByteBuffer(myPointer, 0); // size = 0, you don't want anyone to change it
}

Later, any C++ code can get back the pointer by doing:

return (MyClass *) env->GetDirectBufferAddress(myPointer);

I know the word pointer makes this a bit sour, but maybe it will be helpful to someone some day :-)

HornetQ and Maven

2009-09-02T09:18:00.000-07:00

Andy Taylor has written a nice blog on how to use HornetQ on Maven. Very nice article:

http://hornetq.blogspot.com/2009/09/hornetq-simple-example-using-maven.html

Best Practice on Junit: Always set your fields to null on tearDown

2009-08-11T16:56:00.001-07:00

This was a surprise to me today. Just wanted to share it thourgh a small blog entry, so maybe others are also going through the same thing.

Say you have this test:


public class MyTest extends TestCase
{

    Server server;

    public void setUp()
    {

server

 = new Server();
    }

 public void testOne() throws Exception
 {
        System.gc();
        Thread.sleep(1000);
 }

 public void testSecond() throws Exception
 {
        System.gc();
        Thread.sleep(1000);
 }

public void testThird() throws Exception
 {
        System.gc();
        Thread.sleep(1000);
 }
}

JUnit will hold one instance of MyTest for every method being executed. So if Server is a heavy weight object you will end up with three instances in the memory, until all the test methods on this class are executed.

So, as a best practice on unit tests aways set big objects such as server, connections or anything lilke that to null on a junit test.

JBoss Messaging 2.0 beta 4 is released

2009-07-27T12:16:00.000-07:00

We just released Messaging 2.0 beta 4, and it' s ready to download.

I' m pleased with the progress we are making, and we are excited about what we are doing.

We still have work to do but we are very confident about the quality of the work we are doing.

Look at the documentation and you will know what I' m talking about.

Fedora 11 finally got me...

2009-07-17T08:12:00.000-07:00

I have been using a competitor distribution for very long (about 2 years) even though I work for RedHat / JBoss, just because it was easier. I couldn' t figure out how to do a few things.

I have tried to come to Fedora a few times.. and I could never feel comfortable.

But Fedora 11.. that' s really nice. I would say I don't even feel I'm on Linux. I'm feeling very comfortable like using my wife's Mac OS X :-)

The WebCam works, wireless... video resolution.. even Skype... everything smooth.

It could be also the Lenovo T500 behaves really well with Linux.. but still... Fedora 11 has got me.

I' m a Fedora user from now on :-)

Everybody Loves Lula!

2009-06-26T16:05:00.000-07:00

I just love my president! Maybe he is also wearing a JBoss shirt?

This picture was taken at FISL

Speaking as a brazilian citizen, we had so many highly educated presidents before him, however this government as far as I know has promoted open source in a much better scale than any other previous government.

It is really nice seeing the government promoting open source there.

Performance comparisson on JBoss Remoting and Serialization

2009-02-20T14:07:00.000-08:00

Afonso Olias just made a Nice Post regarding JBoss Remoting and Serialization performance.

JBM2 Getting bigger, JBM2 Getting smaller

2008-09-01T08:00:00.000-07:00

I have aways been posting about how great JBM2 is getting, how fast and how good it will be to support very high performance demands.

But today I want to talk about another aspect. What about small computers? Who knows, maybe you want to distribute messages to and from an ATM.

We have developed a way to page messages to disk, what will avoid the server from running out of memory by storing messages on disk when the memory is low.

There is probably nothing new with that, as JBM 1.4 and JBoss MQ already have it. (Well.. some products out there dont :-) )

The great news here is, this is really fast, and the deployment is really simple.. no RDBMS. We have developed a system where the producers will write directly to NIO files when the memory is low, and the server will start depaging those messages as soon as you have more memory available. (i.e. as soon as you consume some messages).

I have sent 500K messages to a server with only 64M on the JVM without any consumers, and it ran as fast as if they were being consumed. Later when the consumer connected, it started getting the messages as nothing special was happening.

JBM2 just buffered the messages on file protecting the server from running out of memory.

So if you have some hardware with low memory and a hard disk JBM2 still your best choice.

Redeployment leaks fixed on Apache BeanUtils

2008-08-20T15:23:00.000-07:00

I'm really glad as I could use some of my spare time to help this project. Especially because I found a lot of people with redeployment problems, not only on JBAS but in several other projects. Just google it and you will see what I mean.

We have identified some hard to solve memory leaks on BeanUtils caused by very complex circular references on the Reflection metadata which is now fixed.

The use of the jvmti library from jboss-profiler (the same library we use to chase memory leaks on the JBAS testsuite) simplified the process a lot, and even better we have added some testcases preventing regressions, using the same techniques we have applied to solve our own redeployment leakages on JBAS.

You can find more information about what was done here:

BEANUTILS-291

JBM 2 is getting even faster and better

2008-07-30T15:21:00.000-07:00

When we released JBM 2 Alpha1, we released some performance results and we thought they were already great.

I have recently spent a lot of time working on the journal, testing and improving it, making it as reliable as possible, and because of one of the improvements we achieved the Journal is at least 40% faster on persistent messages than it was on JBM 2 alpha. Depending how you configured Alpha that could mean 100% improvement.

We are aways reusing files on the journal, putting them back as fast as we can. Because of the data format we are now using we don't need to refill the file, and that saved a lot of time on I/O as records were being added on the journal.

And what's great is, we still have room for improvements in performance.

JBoss Messaging 2 rocks!

Playing Music, Coding and JBoss Messaging :-)

2008-06-02T08:46:00.000-07:00

Probably not many people know that but I'm also a musician, a Jazz and Bossa Nova piano player and if I invested just a little bit more of my time (which I don't have now :-) ) I could become a professional musician. Some of the feelings I have while playing in a band I'm also getting this week after the JBoss Messaging Alpha release:

I - It's cool to improvise: You feel great by inventing new things and you got that feeling! I have been part of writing a totally cool Asynchronous IO module and helped improving the Persistent of JBoss Messaging. I totally get that feeling here.

II - It's cool when a band (or team) member also improvise: When Jeff Mesnil was working on the new transport, Andy Taylor doing a lot of hard work or Tim Fox orchestrating or playing the whip.. it's all the same... I'm part of the band, and we are jazzing a beautiful song.

III - Applauses! Yeah... musician needs that.. and we are getting that this week.

And the main point is: JBoss Messaging Alpha it's just a rehearsal. It will be much better when we are in concert :-)

It is really cool to be part of this Messaging revolution :-)

Speeding UP IO with Asynchronous IO

2008-05-14T16:40:00.000-07:00

Have you ever wondered how to make IO faster?

We have this dilemma on the messaging world where we need to provide a framework where users are able to send thousands messages per second and we have found our way on doing it, and we are quite excited about it.

In our tests we have been able to send 25,000 persistent messages per second being very close to the the limits of the disk not consuming a lot of CPU on this process, on a computer with 2 QuadCores and a SAS/SCSI disk which is a very modest workstation. And about 10,000 messages/sec on my crappy Laptop because of my slow disk.

We have implemented a very generic JNI layer in top of AIO where you send a Java Callback Interface on every write, and you get informed when the data is on the disk.

With that we avoided requiring to send a sync on every commit we perform. We can just wait for the commit completion so a transaction commit will not affect other transactions.

This JNI layer is also using DMA (Direct Memory Access) when sending the data to the disk, so the CPU will be free doing other things while the data is being written.

At this point we are focusing on making this libaio layer very performatic and stable on JBoss Messaging and depending on the demand we might do it as a separate project very easily since it is ready.

Consider this blog just a teaser. I can't wait the release of JBoss Messaging Alpha showing these numbers so everyone will be able to produce these numbers, and we are almost there. It's amazing to be part of this!

If you want a very fast and reliable Java Messaging System, JBoss Messaging 2 will be your only choice :-)