Hi Bruno !
Bruno Corsi dos Santos a écrit :
Hi,
I'm using the libcarob in a server application
Good to know! Don't hesitate to send us comments or feedback on the
API. Every suggestion for improvement is highly welcome.
The first doubt is about round robin connection policy
that seems it is the default policy. In my
application, I build a poll of connections and
basically the use is: I get one connection from the
poll, use it and return it to the poll. It is
necessary because it would be too expansive create a
new connection on each time I need use one. I think
that when it comes round robin policy, each connection
that I would create should point to a different
controler, e.g., if I create 10 connection (from a
ConnectionParameters object) and I'm using 2
controllers, I think I would have 5 connections to the
first controller and 5 connections to the second
controller. The connections 1, 3, 5, 7 and 9 should be
to the first controler and the connections 2, 4, 6, 8
and 10 should be to the second controller, I mean, the
"round robin concept". But I noticed that all
connections I created were to the first controller,
and the second controller was used just when I "stop"
the first controler, so, in normal conditions, the
second controller woundn't be used.
You're totally right. This issue has been filed as
https://forge.continuent.org/jira/browse/CAROB-96
I'll correct this in the next few hours, check the CVS...
/* Create the object with only one controler */
connectionParameters = new
CarobNS::ConnectionParameters(dbfirstip, dbfirstport,
dbname, dbuser, dbpass);
/* Add a second controler */
connectionParameters->addController(dbsecondip,
dbsecondport);
/* But all connections go to the first controller...
*/
Other doubt is about the use of select syscall to wait
for data at the sockets. I know that select syscall
fails when the number of file descriptors in the
process application exceeds 1024. I didn't checked it
yet in carob, but I've already this problem with other
libraries. So, I think we would make available a
compilation using epoll syscall instead of select
syscall to avoid this problem.
The last doubt is about sequoia performance. I've been
having problems with performance at the sequoia. When
I use just one controler and without replication the
sequoia works well but if I enable replication or use
two controllers the sequoia gets slow and I doesn't
stand the throughput I need. Is there room and
perspectives to improve it?
I let Marc answer to these two questions.
Cheers,
Gilles.
_______________________________________________
Carob mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/carob
