Are Broker and BrokerService Java objects thread safe?


We have a parent java class that creates a broker instance and a brokerservice instance for each RPC call we do. It seems to me when we do this the “poolsize” parm on the broker instance is useless. If we create a broker for each call and the poolsize is specific to a broker instance it will never really be used will it?

So what are the implications if our base class creates a static Broker instance with poolsize? Will be have problems if lots of subclasses are using the same broker instance?


Hi Earnie,

the Broker and BrokerService classes are thread-safe, but: Instances of this class can be used safely in multi-threaded applications. However, all Broker calls going through the same instance of a Broker object will be serialized. Parallel Broker calls are supported when using multiple Broker objects. (quote from the Javadoc of the Broker class).

So if you have only one instance of class Broker you are fine with poolsize=1 :wink:

I have created a pool of Broker objects that are all logged in to Broker. What effect will setting poolsize=50 for example have? I do not understand how this “pool” is implemented.


I’m copying the contents of the servline24 document 45608.

[i]Below is information from the EntireX Documentation on the poolsize and pooltimeout parameters, followed by information from Development on how these settings might effect performance.

From the EntireX v6.1.1 Developer’s Kit documentation:
Java ACI / Java System Properties and Socket Parameters / Socket Parameters for TCP and SSL Communication:

The behavior of the socket pooling can be influenced by two parameters specified as part of the Broker ID. They are used for both TCP and SSL communications. The parameter poolsize specifies the maximum number of socket connections which are kept in the socket pool. If that number is reached, further Broker calls going through a Broker instance are delayed until a socket becomes available. If a multi-threaded application uses blocking sendReceive or Receive calls with a longer waiting time, the poolsize parameter must be at least equal to the number of threads. The default value for the poolsize parameter is 32. Setting the poolsize parameter to 0 disables the socket pooling. The behavior is then identical to that of the pre-6.1.1 versions of EntireX.

Automatic closing of socket connections is controlled by the parameter pooltimeout. If a socket connection has not been used for the specified the number of seconds it will be closed automatically. The default for this parameter is 300 seconds.

Example for using a maximum of 10 socket connections and a timeout of 60 seconds:
Broker broker = new Broker(“yourbroker?poolsize=10&pooltimeout=60”,“userID”);

Supplemental information from Development:

The poolsize/pooltimeout parameters are parameters used by the EntireX Java ACI/RPC runtime. They determine the maximum number of socket connections from the Java application to the Broker; and the time of nonactivity on a Socket until the socket will be closed.

Please note that a socket (from the pool) is not allocated to each user. A socket is retrieved from the pool only for the duration of a Broker call. After the Broker call returns, the socket is put back to the pool and may be retrieved for another user.

In case of a web scenario it can be assumed that 100 simultaneous users do not issue Broker calls permanently without delays. In that case the default 32 seems to be a good choice. It should also be noted that increasing the number of socket connections will only increase the throughput if enough server replicates are available.

Regarding the pooltimeout: there is no blocking on a socket. The open question is how many other applications are talking to the Broker using TCP/IP and if there are limitations, are performance problems either in the TCP/IP stack or in the TCP/IP communicator of the Broker when too many socket connections are open.

Let me try to reformulate the last part.
The pooltimeout specifies the time (how long) a socket connection will stay alive without any activity. The socket can be reused from the Java application when necessary so it is not blocked, but it is unused.

There is no simple answer to the question if the pooltimeout should be short or long. If the pooltimeout is short, sockets will be closed when there is no activity and need to be reallocated when new requests are coming in. On the other hand, each established socket connection to the Broker uses Broker resources (memory). The customer needs to consider the number of (client or server) applications which communicate to the Broker via TCP/IP. [/i]

Please let me know if you have further questions.

This makes sense. Having poolsize > # of RPC servers will create bottlenecks.

Thanks very much for helping me to understand this!


Hello, I read this thraed but I didn´t understood some concepts.
Let me explain our situation:
We have a JAVA web application, that instance a broker object (Entirex).
To instance it, we use the Singleton patron, so, for the running application we have only one instance of the broker object.
Is this a good aproach for the use of the broker ?
Or better is to instance a broker object every time it´s needed ?
How come to play the poolsize with using the singleton ?

Thanks very much for your help !!!

Hello Martin,

you can use a singleton instance of the Broker object. But in case your web app receives multiple calls in parallel they all have to go through this singleton instance and thus will be serialized. It depends on your usage scenario if this might become a performance problem.

Creating a Broker object for every call can be done if you do not have high volume. Each new Broker object creates a new client participant in the Broker Kernel. It’s then your choice to destroy this participant instance directly after the call with logoff() or use the CLIENT-NONACT timeout so the Broker Kernel will handle this. If you have high volume you might run rather soon in the notorious NUM-CLIENT exceeded situation.

The most performant and elegant solution is that you create and keep a pool of Broker instances. In case you are doing RPC I would actually recommend to pool the wrapper object instances and have a 1-to-1 relationship between a wrapper object and a Broker object (things might be a bit different if you are running with security but this is another story …). But of course this requires much more work to be done on your side.

In the case of the singleton object you don’t need to worry about the poolsize, 1 object in the pool is sufficient for this scenario.

Thank you very much !!
I understand this now.
One more cuestion, what do you mean with wrapper object instance ?
thanks again.

The object instance of the Java class which is generated by the EntireX Workbench from an IDL file, in case you are using RPC.

OK, thank you !!!