Develop Reference

Using Aeron with RSocket

Good morning,
I am trying to use RSocket on top of the Aeron transport protocol. However, it appears that there is no documentation on the topic - did anyone successfully integrate those two technologies together ?
Is it ready to be used or still a work in progress ?
Thank you very much.

I chatted with R-socket authors about Aeron's support. They say it's very deep in work in progress.
Currently, they have a big issue with converting R-socket byte buffers (they reuse Netty bb) to UnsafeByteBuffer from Agrona. So they have to copy from one to another just because there is no obvious copy-free converter.
So, answering your question:
Is it ready to be used or still a work in progress?
It's not ready to be used right now unfortunately =(

to wrap or not to wrap an opensource framework? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Should you wrap 3rd party libraries that you adopt into your project?
I am using mail.jar, an opensource api to send mails in java.
I am wondering whether I should wrap its call to my own framework like this :
DedicatedFramework.sendMail(subject, body, recipientList);
this dedicatedFramework would then make the necessary calls to mail.jar.
The idea is that if tomorrow I replace mail.jar with a new version which deprecates/changes methods, then I reduce my coupling.
On the other hand, I add boiler code just to "hide" the framework.
What do you people do regarding this ?
Of course, it could be another framework than mail : picture managing, jdbcTemplate, GoogleCollections ...

No.
Do you know you'll have to use a different mail library tomorrow? Is it even likely? I doubt it. Wrappers just for the sake of "maybe one day" are the worst kind of YAGNI.
On the other hand, if your sendMail() method does something that would otherwise be repeated wherever you send a mail, then it's not a wrapper but a useful abstraction.

Wrap it. Making a bridge between what is available and how it's going to be used is going to save you 1) a lot of boilerplate code and 2) a lot of maintaining that code when something minor changes but you have to make the change in 20 places.
It's entirely possible there is more to this question that isn't being shown. What are our memory constraints? Can we support those extra classes being loaded? We have to identify what problems we would face by doing the wrap, just like any other problem.
However, if there isn't anything that says "We can't wrap because __" then I would recommend doing it.

I would wrap it. It's way easier to find and change code when it's all in one place.

In general, APIs are reasonably stable and classes/methods usually don't disappear, they get deprecated. In your particular case mail.jar is very stable so I wouldn't bother wrapping it.
My advice is to not waste your time writing an API on top of an API - it will cost you more time than it saves in the long run. I've used many libraries over the last decade and the only library I've ever had trouble with was one written by an in-house team - they refactored and changed package names and method names. That broke a lot of code. I've never experienced that with open source libraries.

Wrap
If the framework will be used generally all over your codebase
If it will be a part of project where relatively small number of developers know how to use the framework well
Don't Wrap
If it would be used at just a tiny portion of code that would be very unlikely to change
If the framework or api is realy common knowledge for developers

Kryonet reliability

Is there anyone who has used the Java Kryonet library in a project willing to share their experience? I've seen it recommended a few times, but haven't actually seen anybody talk about their experiences using it.
Specifically, I want to make sure that it is reliable and relatively stable. Or should I consider using something like Google protocol buffers with custom networking code?
Thanks!

I have discussed the kryonet and kryo in my master's thesis and compared it some of the contemporaries; that should give some information and analysis about Kryo: http://de.scribd.com/doc/67084961/MasterArbeit

Answering the other half of your question that isn't addressed by the older one, Protocol Buffers have the advantage of being much more widely deployed, so you're less likely to run into major bugs. There are serious downsides, though, not least the facts that (1) you have to define your format using an IDL and then use PB's generated classes (meaning you may have to copy data in and out of your own back-end objects, which might result in lower performance) and (2) PB doesn't support polymorphism except through a variety of difficult-to-manage hacks.
So, if you're just looking for a straightforward way of transferring structured (but not object-oriented) data from one endpoint to another, Protocol Buffers is probably your best bet. More complex scenarios probably favour Kryonet.
HTH

I developed a game with kryonet and it works like a charm. It is also very easy to use.

I am currently working with Kryonet and making a game. I have myself found it as a very helpful and easy to use library. It has a very simple API which makes life very easy. I won't say it is as powerful as something like Netty or Apache Mina but it does all the required tasks. I personally love it and I will use it everywhere I can unless I require something more powerful or sending huge data as other libraries provide much more than KryoNet when it comes to sending data.

Is there a Java equivalent to libevent?

I've written a high-throughput server that handles each request in its own thread. For requests coming in it is occasionally necessary to do RPCs to one or more back-ends. These back-end RPCs are handled by a separate queue and thread-pool, which provides some bounding on the number of threads created and the maximum number of connections to the back-end (it does some caching to reuse clients and save the overhead of constantly creating connections). Having done all this, though, I'm beginning to think an event-based architecture would be more efficient.
In searching around I haven't found any equivalents to libevent for Java, but maybe I'm not looking in the right place? Mina-statemachine from Apache was the closest thing I found, but it looks more verbose than I need and there's no real release available.
Any suggestions?

I am a bit late but:
Have you looked at Netty?
Or Grizzly.

How about the Light Weight Event System? :) http://www.lwes.org/ and http://sourceforge.net/projects/lwes/files/

The answer seems to be 'no', though it looks like the Ruby EventMachine library provides a Java implementation for JRuby users that might be usable or at least serve as inspiration for writing my own:
http://github.com/eventmachine/eventmachine/tree/master/java/

You might be looking for a workflow engine like
JBPM or any other open source tool listed here.

Java concurrent recursive website download

I need to do a program to download the webpages, that is, I give a webpage to the software and it would download all the files in the website.
I would pass also a level of depth, that is, the level where the software goes download each file of the website.
I will develop this software in Java and I need to use concurrency also.
Please, tell me your opinion about how to do this.
Thanks for the help.
Thanks to everyone for the help.
I need to ask one more thing. How do I do to download a file from the website?
Thaks one more time. =D

A very useful library for spiders and bots: htmlunit

Well, this is a bit hard to answer without knowing how detailed guidance you need, but here's an overview. :)
Java makes such applications quite easy, actually, since both HTTP-requests and threading are readily available. My solution would probably involve a global stack containing new urls, and a farm of a constant number of threads that pop urls from the stack. I'd store the urls as a custom object, so that I could keep track of the depth.
I think your main issue here will be with sites that doesn't respond, or doesn't follow the HTTP standard. I've noticed many times in similiar applications that sometimes these doesn't time out properly, and eventually they end up blocking all the threads. Unfortunately I don't have any good solutions here.
A few useful classes as a starting point:
http://java.sun.com/javase/6/docs/api/java/lang/Thread.html
http://java.sun.com/javase/6/docs/api/java/lang/ThreadGroup.html
http://java.sun.com/javase/6/docs/api/java/net/URL.html
http://java.sun.com/javase/6/docs/api/java/net/HttpURLConnection.html

I would look at this recourses:
http://hc.apache.org/httpclient-3.x/
http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html
http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/package-summary.html

I would have a look at the Java Executors package. You create a set of tasks (Runnables) and pass them to a suitable chosen Executor. You get a Future back and you can then query this for its result.
The Executor will coordinate when this Runnable is executed. Implementations exist for single-threaded executors, executors with a pool of threads etc. So you don't need to worry (too much) wrt. the threading intricacies. The concurrency utilities will look after this for you.
Apache HTTP Client will look after the HTTP querying for you.