I have created a weblogic JMS connection factory and tried to access that from other weblogic server in other machine by using JNDI lookup. so when we do JNDI lookup does the Complete Connection Factory object is transferred to the client side or only the reference to that object is given to that client.
Well you ought to know, it's your factory.
If it is an exported remote object, a remote reference is transferred, otherwise
If it is Serializable, it is transferred bodily, otherwise
a NotSerializableException is thrown.
Related
I am try planning to introduce Apache Ignite into existing old .net web api project to use it as key/value store for detecting duplicate requests sent to the load balanced api.
I would like to introduce minimum overhead to each request.
As I understand Client node is communicating to the server through TCP.
My current go to plan is to create a singleton object which will establish connection to the remote cache and register it in my DI container.
Is it ok to leave node running and TCP connection open or should make the ignite object scoped to start close on each request/response cycle?
Keep in open, as a singleton.
Ignite object is thread safe
It is expensive to create and connect to the cluster (in case of classic "Thick" client)
There is also a "Thin" client, which is very lightweight and can be created and disposed often. Note that thin client is also thread safe.
Also, you can try to use REST:
https://apacheignite.readme.io/docs/rest-api
My app is trying to access DataSource through JNDI on Weblogic(12) Server. The following exception is thrown
weblogic.jdbc.common.internal.RmiDataSource_12212_WLStub cannot be cast to javax.sql.DataSource
Where is this class weblogic.jdbc.common.internal.RmiDataSource_12212_WLStub coming into picture.
From My Oracle Support (Doc ID 2005891.1) Version 12.1.1.0 and later
The remote datasource lookup over RMI is not supported with any thin client jar file.
The Wlthint3client.jar library does not support remote datasource lookup over RMI as the required stub classes are not bundled with this jar file, and hence the error.
JDBC over RMI is also deprecated in general and it can easily be a significant security vulnerability.
It normally works with the full WLS client jar library. But it is also not recommended - as this feature is currently deprecated and it might be completely removed in the future release.
Alternatives are to use the JDBC driver if you want to create connections to the database from a remote client, or deploy a local EJB which acquires the connection by doing a local lookup of the datasource.
The WebLogic full client, wlfullclient.jar, is deprecated as of WebLogic Server 12.1.3 and may be removed in a future release. Oracle recommends using the WebLogic Thin T3 client or other appropriate client depending on your environment. For more information on WebLogic client types.
Reference Link
https://docs.oracle.com/middleware/12213/wls/SACLT/jarbuilder.htm#SACLT240
The hornet Q documentation mentions that
A pooled-connection-factory looked up in JNDI or injected which is
referencing an in-vm-connector is suitable to be used by a local
client only to send messages to a local server. A
pooled-connection-factory used by an MDB which is referencing an
in-vm-connector is suitable only to consume messages from a local
server.
https://docs.jboss.org/author/display/WFLY8/Messaging+configuration#Messagingconfiguration-JMSConnectionFactories
Question - Why does the WILDFLY team recommend that pooled-connection factory not be used to receive messages via JNDI? What would be the expected impact if it's used that way?
I have an implementation that uses pooled-connection factory to receive message via a JNDI lookup and I am trying to understand what expected impact we should look for (no issues observed)?
We are trying using HornetQ for messaging on Jboss AS 7.1 and the documentation at
https://docs.jboss.org/author/display/AS71/Messaging+configuration
says
There is also a pooled-connection-factory which is special in that it leverages the outbound adapter of the HornetQ JCA Resource Adapter. It is also special because:
* It is only available to local clients, although it can be configured to point to a remote server.
* As the name suggests, it is pooled and therefore provides superior performance to the clients which are able to use it. The pool size can be configured via the max-pool-size and min-pool-size attributes.
* It should only be used to send (i.e. produce) messages.
* It can be configured to use specific security credentials via the user and password attributes. This is useful if the remote server to which it is pointing is secured.
Every thing made sense except the third bullet which says
* It should only be used to send (i.e. produce) messages.
My mdb uses Pooled connection factory and is consuming messages (Not sending).
My understanding is Pooled connection factory is what the MDB should use for better performance. Also the hornetq Author's say
http://hornetq.blogspot.com/2011/06/hornetq-on-jboss-as7.html
The pooled connection factories also define the incoming connection factory for MDB's,
the name of the connection factory refers to the resource adapter name used by the MDB,
Can some guru's throw some light on this ?
Thanks
Rama
This is something we try to make it easier for users but still some confusion.
the JCA Adapter specifies InBound Connections and Outbound connections...
InBound connections are used by MDBs and outBounds are done through using the JNDI and instantiating connections.
InBound connections don't need pooling for instance as they just instantiate the consumers for the MDBs and stay up as long as you have an MDB...
We keep definitions on the PooledConnection factories for defining the MDBs but underneath there are a few things happening as I said.
So, we could maybe reword this item you mentioned to explain that better.
I have a misunderstanding regarding the connection handle sharing in JCA.
I want to know if the connection sharing only happens during a phase of transaction ( multiple components call ) or the connection sharing is possible amongst multiple clients accessing a component that has the same EIS destination.
I created my own resource adapter on Glassfish application server 3.1. The problem is the resource adapter doesn't perform any connection sharing (no associateConnection method call).
Thanks,