GridLink: oracle.repackaged.ons.ReceiverThread.run and oracle.repackaged.ons.SenderThread.run

We have 7 GridLink Datasources, all configured with the same ONS parameter (same host and port).

However, we have 21 (=7*3) threads with oracle.repackaged.ons.ReceiverThread.run, and 21 with oracle.repackaged.ons.SenderThread.run.

I wonder why:

a) 3 Receiver threads and 3 Sender threads are required per each Datasource

b) why all these Datasources could simply not SHARE the same Receiver and Sender threads, since most likely they will be sharing exactly the same informations.

We also have 7 threads oracle.repackaged.ucp.jdbc.oracle.ONSRuntimeLBEventHandlerThread.run. And 21 tcp ESTABLISHED connections to ONS.

I really don't like having 42 threads dedicated only to Grdilink notifications (plus all the sockets open by them)

GridLink DataSorce becomes generic

I have learned a funny thing: when you create a GridLink DataSource, and you don't enable FAN and ONS, the DataSource appears as "generic" in the "Summary of JDBC Data Sources"

On the other hand, if you create a "generic" DataSorce, it still has a ONS tab, and if you enable ONS, the DataSorce magically becomes "gridlink".

In fact even the WLST script necessary to create the resource is exactly the same - apart the extra instructions needed to set the ONS-FAN (Oracle Notification Service - Fast Application Notification) events. The only difference is the extra

cmo.setFanEnabled(true)
cmo.setOnsNodeList('myoracledbserver.com:6200')


(see here for a complete script)

There is no createJDBCSystemResource specific to GridLink.