Creating 2 managed connections using different ConnectionReq

[andrej]

Hi all!

I want to use a JCA to handle connections to an ERP system, so I can't definitely know, where the ERP server is located and security information may differ every time the connection is established. So I use some properties files to define information I need to set up connection. Everything works ok with the first connection (managed connection is created, stored to pool, I can get it from pool):

16:26:33,091 INFO [STDOUT] [Reference Bean log] -> info: Set session context
16:26:33,211 INFO [STDOUT] [Reference Bean log] -> info: Creating...
16:26:33,211 INFO [STDOUT] [Reference Bean log] -> info: Creating initial context...
16:26:33,211 INFO [STDOUT] [Reference Bean log] -> info: Creating initial context done
16:26:33,211 INFO [STDOUT] [Reference Bean log] -> info: lookupFactory: Looking up connection factory...
16:26:33,221 INFO [STDOUT] [Reference Bean log] -> info: result of lookup is: com.om.onec.cci.ConnectionFactoryImpl@911
540
16:26:33,221 INFO [STDOUT] [Reference Bean log] -> info: lookupFactory: Looking up connection factory done
16:26:33,682 INFO [STDOUT] [ManagedConnectionFactory] -> createManagedConnection()...
16:26:33,712 INFO [STDOUT] *==============================
16:26:33,712 INFO [STDOUT] * Initialization Information:
16:26:33,712 INFO [STDOUT] *
16:26:33,712 INFO [STDOUT] * Using server on: 127.0.0.1
16:26:33,722 INFO [STDOUT] * NT domain: HOMELAN
16:26:33,722 INFO [STDOUT] * User name: Nio
16:26:33,722 INFO [STDOUT] * User password: ******** (hidden for security purposes)
16:26:33,722 INFO [STDOUT] *==============================
16:26:33,722 INFO [STDOUT] * Database information:
16:26:33,722 INFO [STDOUT] *
16:26:33,722 INFO [STDOUT] * Database user: InternetUserName
16:26:33,722 INFO [STDOUT] * Database password: ******** (hidden for security purposes)
16:26:33,722 INFO [STDOUT] * Path to database: h:\demodbb
16:26:33,722 INFO [STDOUT] *==============================
16:26:33,732 INFO [STDOUT] [ManagedConnectionImpl] -> setting up 1C object...
16:26:41,132 INFO [STDOUT] [ManagedConnectionImpl] -> 1C object succesfully created...
16:26:41,393 INFO [STDOUT] /D"h:\demodbb" /NInternetUserName /P111
16:26:41,393 INFO [STDOUT] RMTrade=com.linar.jintegra.Variant@93bca2
16:26:41,403 INFO [STDOUT] [ManagedConnectionImpl] -> 1C Initialization...
16:26:53,921 INFO [STDOUT] [ManagedConnectionImpl] -> 1C has been initialized...
16:26:53,981 INFO [STDOUT] [ManagedConnectionImpl] -> adding connection listener...
16:26:53,981 INFO [STDOUT] [ManagedConnectionImpl] -> getConnection()...
16:26:53,981 INFO [STDOUT] [ManagedConnectionImpl] -> adding object: com.om.onec.cci.ConnectionImpl@3da850
16:26:53,991 INFO [STDOUT] [ManagedConnectionImpl] -> object succesfully added...
16:26:53,991 INFO [STDOUT] [Reference Bean log] -> info: Retrieving connection done

Next stage, I want to use this created connection as an source of information and I need another connection on other server to store information i got using first connection. So I need to use both of connections, to get information from first connection and to put information to another one. But I CAN'T do that! When I'm trying to transfer another parameters, I get an exception:

16:35:29,742 INFO [STDOUT] [ManagedConnectionFactory] Search for matching connections in the set of 1
16:35:29,752 INFO [STDOUT] [ManagedConnectionImpl] -> adding object: com.om.onec.cci.ConnectionImpl@275a34
16:35:29,752 INFO [STDOUT] [ManagedConnectionImpl] -> object succesfully added...
16:35:29,752 INFO [STDOUT] [Reference Bean log] -> info: Remove actions...
16:35:29,752 INFO [STDOUT] [Reference Bean log] -> info: Cleaning objects in current thread...
16:35:29,762 INFO [STDOUT] [Reference Bean log] -> info: ...done
16:35:29,762 INFO [STDOUT] [Reference Bean log] -> info: Closing connection...
16:35:29,762 INFO [1CConnector] [ManagedConnection] -> cleanup()
16:35:29,762 INFO [1CConnector] [ManagedConnection] -> cleanup()
16:35:29,762 INFO [STDOUT] [Reference Bean log] -> info: Closing connection done
16:35:29,762 INFO [STDOUT] [Reference Bean log] -> info: Removed
16:36:18,452 INFO [STDOUT] [Reference Bean log] -> info: Set session context
16:36:18,452 INFO [STDOUT] [Reference Bean log] -> info: Creating...
16:36:18,452 INFO [STDOUT] [Reference Bean log] -> info: Creating initial context...
16:36:18,472 INFO [STDOUT] [Reference Bean log] -> info: Creating initial context done
16:36:18,482 INFO [STDOUT] [Reference Bean log] -> info: lookupFactory: Looking up connection factory...
16:36:18,482 INFO [STDOUT] [Reference Bean log] -> info: result of lookup is: com.om.onec.cci.ConnectionFactoryImpl@911
540
16:36:18,482 INFO [STDOUT] [Reference Bean log] -> info: lookupFactory: Looking up connection factory done
16:36:18,482 INFO [STDOUT] [ManagedConnectionFactory] Search for matching connections in the set of 1
16:36:18,482 ERROR [STDERR] javax.resource.ResourceException: Error in use of ManagedConnectionPool: matchManagedConnect
ion failed with subject: null and ConnectionRequestInfo: com.om.onec.spi.ConnectionRequestInfoMap@1b6334e9
16:36:18,492 ERROR [STDERR] at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(Inte
rnalManagedConnectionPool.java:98)
16:36:18,492 ERROR [STDERR] at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnectio
n(JBossManagedConnectionPool.java:323)
16:36:18,492 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(Base
ConnectionManager2.java:467)
16:36:18,492 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseCo
nnectionManager2.java:532)
16:36:18,492 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.al
locateConnection(BaseConnectionManager2.java:814)
16:36:18,492 ERROR [STDERR] at com.om.onec.cci.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:89)
16:36:18,492 ERROR [STDERR] at Session.remote.reference.ReferenceBean.getConnection(ReferenceBean.java:91)
16:36:18,492 ERROR [STDERR] at Session.remote.reference.ReferenceBean.ejbCreate(ReferenceBean.java:186)
16:36:18,492 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:36:18,502 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
16:36:18,502 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
16:36:18,502 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
16:36:18,502 ERROR [STDERR] at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.createSession(StatefulSes
sionFilePersistenceManager.java:162)
16:36:18,502 ERROR [STDERR] at org.jboss.ejb.StatefulSessionContainer.createHome(StatefulSessionContainer.java:441)
16:36:18,502 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:36:18,502 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
16:36:18,502 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
16:36:18,502 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
16:36:18,502 ERROR [STDERR] at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invokeHome(StatefulSessio
nContainer.java:756)
16:36:18,522 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:105)
16:36:18,522 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedCon
nectionInterceptor.java:215)
16:36:18,522 ERROR [STDERR] at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionIn
stanceInterceptor.java:128)
16:36:18,522 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:111
)
16:36:18,522 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:151)

16:36:18,522 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:52)
16:36:18,522 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:129)
16:36:18,522 ERROR [STDERR] at org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:368)
16:36:18,532 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:730)
16:36:18,733 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
16:36:18,733 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
16:36:18,733 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:36:18,733 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
16:36:18,753 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
16:36:18,753 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
16:36:18,753 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
16:36:18,753 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Unknown Source)
16:36:18,753 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
16:36:18,763 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Unknown Source)
16:36:18,763 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
16:36:18,763 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
16:36:18,793 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)
16:36:18,793 INFO [STDOUT] [Reference Bean log] -> info: Unable to connect to adapter. System will fail to continue.
16:36:18,793 ERROR [STDERR] java.lang.NullPointerException
16:36:18,793 ERROR [STDERR] at Session.remote.reference.ReferenceBean.ejbCreate(ReferenceBean.java:198)
16:36:18,803 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:36:18,803 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
16:36:18,803 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
16:36:18,803 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
16:36:18,803 ERROR [STDERR] at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.createSession(StatefulSes
sionFilePersistenceManager.java:162)
16:36:18,813 ERROR [STDERR] at org.jboss.ejb.StatefulSessionContainer.createHome(StatefulSessionContainer.java:441)
16:36:18,813 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:36:18,823 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
16:36:18,823 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
16:36:18,823 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
16:36:18,843 ERROR [STDERR] at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invokeHome(StatefulSessio
nContainer.java:756)
16:36:18,843 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:105)
16:36:18,843 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedCon
nectionInterceptor.java:215)
16:36:18,843 ERROR [STDERR] at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionIn
stanceInterceptor.java:128)
16:36:18,843 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:111
)
16:36:18,843 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:151)

16:36:18,843 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:52)
16:36:18,843 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:129)
16:36:18,853 ERROR [STDERR] at org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:368)
16:36:18,853 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:730)
16:36:18,853 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517)
16:36:18,853 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382)
16:36:18,853 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
16:36:18,853 ERROR [STDERR] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
16:36:18,853 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
16:36:18,853 ERROR [STDERR] at java.lang.reflect.Method.invoke(Unknown Source)
16:36:18,853 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
16:36:18,853 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Unknown Source)
16:36:18,853 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method)
16:36:18,863 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Unknown Source)
16:36:18,863 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
16:36:18,863 ERROR [STDERR] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
16:36:18,863 ERROR [STDERR] at java.lang.Thread.run(Unknown Source)

I looked throw the source code of InternalManagedConnectionPool.java (getConnection method) and found out JBoss can't handle connections with different connection information. It takes first connection from pool (number of connections are defined in deployment descriptor). If there is no connections, it creates one, or another case transferres it (retreived connection) to a matchManagedConnection method of ManagedConnectionFactory. So last log displays, when my matchManagedConnection returnes null, I get such an exception. Why is it so?

[andrej]

In addition, I use jboss 3.0.4 + Tomcat 4.1.12, on winXP

[davidjencks]

There are 2 problems:

1. jboss returns an connection in an existing transaction before it looks at the ConnectionRequestInfo. This is a bug. Work around it by setting up 2 connection pools.

2. It isn't clear to me that you have specified byApplication for the pool and that the ConnectionRequestInfo objects you provide will distinguish between the server instances. You need to do this or jboss will have no way to guess at which connection to try to match.

The pooling implementation is quite pluggable, so if you don't like the partitioning scheme I implemented you are free to try another. You can also try to convince me that some other scheme is needed, but so far no one has succeeded or tried very hard.

BTW the spec explicitly states that you should not use the ConnectionRequestInfo contents to select which server you are connecting to.

[darranl]

Setting the connection pool criteria to 'ByApplication' and implementing the equals and hashCode methods on a ConnectionRequestInfo object that contains the remote server details does allow different server instances to be identified by JBoss, it sounds like I am trying to achieve something similar to you connecting to different servers.

The error that was raised by JBoss however is a JBoss fault, the resource adapter should be allowed to return null from matchManagedConnections so a new connection will be created.

16:36:18,482 ERROR [STDERR] javax.resource.ResourceException: Error in use of ManagedConnectionPool: matchManagedConnect
ion failed with subject: null and ConnectionRequestInfo: com.om.onec.spi.ConnectionRequestInfoMap@1b6334e9

Regarding the specs description of what to put into the ConnectionRequestInfo object the spec says:-

It is important to note that the properties passed through the ConnectionRequestInfo instance should be client-specific (example: user name, password, language) and not related to the configuration of a target EIS instance (example: port number, server name).

I have three different departments, each running the same legacy system that I need to connect to to pass XML messages to.

Would it be appropriate for the ConnectionRequestInfo object to contain some other identifier such as department name and let the ManagedConnection handle the mapping from department name to IP address and port? Or is this still a mis-use of the ConnectionRequestInfo object?

[darranl]

Setting the connection pool criteria to 'ByApplication' and implementing the equals and hashCode methods on a ConnectionRequestInfo object that contains the remote server details does allow different server instances to be identified by JBoss, it sounds like I am trying to achieve something similar to you connecting to different servers.

The error that was raised by JBoss however is a JBoss fault, the resource adapter should be allowed to return null from matchManagedConnections so a new connection will be created.

16:36:18,482 ERROR [STDERR] javax.resource.ResourceException: Error in use of ManagedConnectionPool: matchManagedConnection failed with subject: null and ConnectionRequestInfo: com.om.onec.spi.ConnectionRequestInfoMap@1b6334e9

Regarding the specs description of what to put into the ConnectionRequestInfo object the spec says:-

It is important to note that the properties passed through the ConnectionRequestInfo instance should be client-specific (example: user name, password, language) and not related to the configuration of a target EIS instance (example: port number, server name).

I have three different departments, each running the same legacy system that I need to connect to to pass XML messages to.

Would it be appropriate for the ConnectionRequestInfo object to contain some other identifier such as department name and let the ManagedConnection handle the mapping from department name to IP address and port? Or is this still a mis-use of the ConnectionRequestInfo object?

[darranl]

Setting the connection pool criteria to 'ByApplication' and implementing the equals and hashCode methods on a ConnectionRequestInfo object that contains the remote server details does allow different server instances to be identified by JBoss, it sounds like I am trying to achieve something similar to you connecting to different servers.

The error that was raised by JBoss however is a JBoss fault, the resource adapter should be allowed to return null from matchManagedConnections so a new connection will be created.

16:36:18,482 ERROR [STDERR] javax.resource.ResourceException: Error in use of ManagedConnectionPool: matchManagedConnection failed with subject: null and ConnectionRequestInfo: com.om.onec.spi.ConnectionRequestInfoMap@1b6334e9

Regarding the specs description of what to put into the ConnectionRequestInfo object the spec says:-

It is important to note that the properties passed through the ConnectionRequestInfo instance should be client-specific (example: user name, password, language) and not related to the configuration of a target EIS instance (example: port number, server name).

I have three different departments, each running the same legacy system that I need to connect to to pass XML messages to.

Would it be appropriate for the ConnectionRequestInfo object to contain some other identifier such as department name and let the ManagedConnection handle the mapping from department name to IP address and port? Or is this still a mis-use of the ConnectionRequestInfo object?

[darranl]

Setting the connection pool criteria to 'ByApplication' and implementing the equals and hashCode methods on a ConnectionRequestInfo object that contains the remote server details does allow different server instances to be identified by JBoss, it sounds like I am trying to achieve something similar to you connecting to different servers.

The error that was raised by JBoss however is a JBoss fault, the resource adapter should be allowed to return null from matchManagedConnections so a new connection will be created.

16:36:18,482 ERROR [STDERR] javax.resource.ResourceException: Error in use of ManagedConnectionPool: matchManagedConnection failed with subject: null and ConnectionRequestInfo: com.om.onec.spi.ConnectionRequestInfoMap@1b6334e9

Regarding the specs description of what to put into the ConnectionRequestInfo object the spec says:-

It is important to note that the properties passed through the ConnectionRequestInfo instance should be client-specific (example: user name, password, language) and not related to the configuration of a target EIS instance (example: port number, server name).

I have three different departments, each running the same legacy system that I need to connect to to pass XML messages to.

Would it be appropriate for the ConnectionRequestInfo object to contain some other identifier such as department name and let the ManagedConnection handle the mapping from department name to IP address and port? Or is this still a mis-use of the ConnectionRequestInfo object?

[davidjencks]

[I sure hope the replacement for this lame forum system is ready soon. Half the time I can't log in, the other half new posts never show up]

1. Several people have ignored the spec successfully:-) and set up adapters that actually connect to different EIS based on either Subject or CRI, so I don't really see any problem doing that in any way you want. I should have pointed this out in my first reply. I'm not aware of any problems that this could raise.

2. I think the latest pooling code will go through the entire pool looking for a match, but it will destroy connections that don't match (and it thinks they should). Before I change this I'd really like to see a reasonable example of a matching algorithm whose results can't be predicted from comparing Subject and CRI.

[darranl]

[Hopefully I wont post this reply more that once this time!!]

The main problem that I have is that the JBoss JCA implementation is that it is hard coded to always try and use the least recently used connection, my connections will be to routers that will be incurring call charges for the duration of the connection. After a peak demand on the server a lot of connections will have been created, if there is then steady throughput it is quite possible for all of the connections to be regularly used and none of the connections will be removed due to the IdleTimeoutMinutes value.

I was hoping to use the matchManagedConnections method to always pick say the 5th most recently used connection, that way after a peak the excess connections will be destroyed leaving me with a suitably sized pool for the normal load.

At the moment the matchManagedConnections method is just being used to double check that the connection is Ok, there is no other benefit in using the matchManagedConnections method.

[davidjencks]

Hmmm, maybe picking the least recently used was not such a good choice. As I understand it your problem would be solved if we always picked the most recently used to try?

Can you or anyone think of any problems with always trying to match with the most recently used connection? Is there any reason to make the order configurable?

[darranl]

The reason that I sugested that my adapter would want to pick the 5th (Or any other number) most recently used connection was to allow it to try and keep the number of connections in the pool relatively stable, this way there would be a certain number of connections that were regularly used.

My thought there might have been influenced by the implementation of the connection pool within JBoss. At the moment I think the connection pool first removes all of the connections that have been idle for the idleTimeout period and then re-populates the pool to bring it back up to the minimum pool size.

If JBoss only removed idle connection that wouldn't take the size of the pool below the maximum pool size then that would also help to keep the pool size at the required size without destoying and creating connections unnecessarily. The disatvantage that I can see with this is if you know that the host system will automatically diconnect idle connections after say 15 minutes and you want to configure JBoss to automatically reconnect at the time the automatic disconnect would occur.

If there was any way that JBoss could pick the connection to use based on the minimum pool size e.g. If there is a minumum pool size set of 5 JBoss could then always use the 5th most recently used connection. This way you would get the connections created due to a peak load to be removed, the optimum number of connections would be regularly used if there is a steady throughput and you would still get idle connections destroyed and recreated to cope with the host systems disconnecting.