Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm implementing a throttling mechanism to limit the amount of web requests sent to a server. If there are too many submissions for a request then the extra requests are queued until the resource becomes available. There seems to be many throttling options and im not sure which one to choose.
So far im tempted to implement the token bucket algorithm as described at http://en.wikipedia.org/wiki/Token_bucket . There is Python code associated with this at What's a good rate limiting algorithm? so should be straightforward to implement a Java/Scala version.
Guava has what looks like a nice implementation described at http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/RateLimiter.html
Also Akka seems to implement throttling using the Throttler trait described at : http://doc.akka.io/api/akka/2.1.2/index.html#akka.contrib.throttle.Throttler
I would like to implement my own but don't like re-inventing the wheel if there is a solution already available. Are there advantages to using the token bucket algorithm over using the options already provided by Guava & Scala ?
Out of the three options which is most recommended ?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm creating rest service for mobile app in java. For storage process which is best suitable for real time storage (Hibernate , JPA & JDBC).
Your valuable answers will put me on right track.
Basically ORM technologies like Hibernate, JPA etc., provides greater flexibility to the programmer in maintaining the code say for example, direct mapping to java POJO's, object locking mechanisms, Id generation and lot more with little cost of performance. If your application needs light weight calls (taking into consideration of concurrency, ofcourse underling database will provide, small relation etc) you could opt JDBC.
Thanks,
JK
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
there seems to be many ways to access a REST web service. but different documentation out there states they all have problems and now i am confused what to use.
Here are our options:
HTTPClient - from apache, but deprecated. However Apache does provide some alternative
HttpURLConnection - has bugs in it.
AndroidHttpClient - includes the workaround for a major bug in HttpURLConnection
I really don’t know which one to use from the list above. Is there one which I am missing that I should be using
to access a REST web service ?
Ideally, to access a REST Web service, you use a higher-level library, like Retrofit, that handles more of the work for you.
Otherwise, Google's official recommendation is to use HttpURLConnection.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
In my team we are trying to decide what path to take, if Scala (somehow unknown) or Java (very well known).
We are completely bought that our problem would be best solved by an actor type system, hence Akka but we lack Scala proficiency.
What benefits would there be to using the scala library over java library to do this project?
Akka does asynchronous I/O using Java NIO - so one thread can handle many simultaneous requests. Traditional Java server frameworks use one-thread-per-socket I/O. So, if you need your code to scale to, say, 10K open connections on a single VM, without needing to spawn 10K threads to do it, then you probably want something asynchronous.
There are Java-language frameworks such as Netty or Atmosphere which also do asynchronous I/O - so you don't have to use Scala if your team is already adept at Java.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I currently need to resolve an issue with duplicated logic on web-based monitoring (Java) and a big legacy C server app.
For this I need to build new clients for the C app, but I have no idea what formats are good for Java to read.
Should I use XML, Json, or some other format?
The answer is completely dependent on your problem domain. Java has libraries available for reading XML, JSON and a host of other protocols.
You need to be asking questions like:
How much data will I be producing?
Does the data need to be human-readable?
Is storage size an issue?
Is the time to read / write the data an issue?
Do I need to support multiple, versioned protocols?
You can use either, JSON is the new standard for web-based messages and there are plenty of Java libraries to handle JSON efficiently.
There's no one stop perfect fit here, but maybe Google's protobuf is a good idea?
There's a native C++ compiler, which is probably of no use to you; there's an active protobuf-c implementation that you might be able to use, though.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
can someone pleas tell a few good alternatives to corba.
If you need support for more than a language Thrift could be a good solution. It is widely used at Facebook.
As per: https://cajo.dev.java.net/
The cajo project is a small, 100% Free library, enabling powerful dynamic multi-machine coöperation; both within and between, both free and proprietary Java applications. It is a surprisingly easy to use, yet completely understandable framework, unmatched in performance. It is actively being deployed in Java EE, SE, and ME environments all over the world. It is a uniquely 'drop-in' distributed computing framework: meaning it imposes no structural requirements on your applications, nor source changes. It allows multiple remote JVMs to work together seamlessly, as one.