JNDI Connection continually dropping

I have created a new data connection in the server administrator which is being successfully used by my database publishing templates. However, the connection seems to be continually dropped, and seemingly not related to any particular activity.

Every time the connection is dropped, I have to go to the Database Explorer tab in the workbench and right-click/refresh the tables node. The JNDI database connection tester then reports an OK connection rather than the unable to connect message.

I raised a tech support call about this but wondered if this is a known problem. 6.5.2, SQL Server 2000.

Ach, from the manual:

SecurityException - Invalid Authentication Attempt
You get a fatal error, and the first line of the error text reads java.lang.SecurityException:
Invalid authentication attempt, principal=null.
402 Rhythmyx Implementation Guide

Meaning: In your datasource file (<Rhythmyx root>/AppServer/server/rx/deploy/<filename>-ds.xml file), you have a <security-domain> element. Open your datasource file and comment out the element. See Creating a Datasource for your Target Database (see page 365) for information on the datasource file.

I’ve never seen this problem, but when connecting to the Repository, I’d recommend that you use the “null” database connection. This will cause $rx.db.get() to use the same connection pool as the Rhythmyx server, and should cause you less trouble.

Dave

Had to remove the security-domain element from my datasource definition file and add in username and password elements. The manual provided manual instructions but of course I used the Server Administrator thinking there wouldn’t be a significant difference.

All works now, no more dropping connection.

Och it doesn’t continue working at all, because even if you set up the database connection manually exactly as described in the manual as soon as you open the Server Administrator and apply any changes the entry for your data connection gets edited back to not include the user-name and password elements and it re-inserts the security-domain element.

We are having a similar problem when trying to do database publishing. The database connection is getting dropped and we hit a Fatal Error during the publish:

[SIZE=“2”]java.lang.SecurityException: Invalid authentication attempt, principal=null
at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:665)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:461)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:894)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:73)
at com.percussion.tablefactory.PSJdbcDbmsDef.getConnection(PSJdbcDbmsDef.java:604)
at com.percussion.tablefactory.PSJdbcTableFactory.getConnection(PSJdbcTableFactory.java:975)
at com.percussion.publisher.client.PSDatabasePublisherHandler$DbmsConnection.<init>(Unknown Source)
at com.percussion.publisher.client.PSDatabasePublisherHandler.connectToDatabase(Unknown Source)
at com.percussion.publisher.client.PSDatabasePublisherHandler.performAction(Unknown Source)
at com.percussion.publisher.client.PSDatabasePublisherHandler.publish(Unknown Source)
at com.percussion.publisher.client.PSContentItem.publish(Unknown Source)
at com.percussion.publisher.client.PSContentItem.process(Unknown Source)
at com.percussion.publisher.client.PSContentPublisher.process(Unknown Source)
at com.percussion.publisher.client.PSContentPublisher.execute(Unknown Source)
at sun.reflect.GeneratedMethodAccessor7479.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.soap.server.RPCRouter.invoke(RPCRouter.java:146)
at org.apache.soap.providers.RPCJavaProvider.invoke(RPCJavaProvider.java:129)
at org.apache.soap.server.http.RPCRouterServlet.doPost(RPCRouterServlet.java:354)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Unknown Source) [/SIZE]

In order to be able to publish to the database we are having to go into the workbench to the Database Explorer tab and expand the Table folder for the target Database that we are publishing to. After doing this we don’t hit the error during the publish process.

We have other (file publish) templates that are pulling data from this database without a problem using $rx.db.get().

Any ideas why the connection may be getting dropped for the publisher?

Thanks,
Veeren

I happened to come across this post in the forum which seems to explain why the connection is being dropped and also provides a solution:

[QUOTE=JaySeletz;2203]Responding to these posts:

The issue is that you cannot use datasources created via the Rhythmyx Server Administrator with Database Publishing. The reason is that the password encryption scheme used for these datasources is tied to the Rhythmyx web application (rxapp.war), and doesn’t work from the publisher web app (rxservices.war). The JndiTest page is in the rxservices.war application, and so cannot create connections using datasources that have passwords encrypted in this manner.

This may seem to work intermittenly and unreliably if the connections are first successfully created from within the Rhythmyx webapp (e.g. by using the workbench Database Explorer) - these connections are added to the JBoss connection pool and will work from any web app while they remain alive. Once they time out, the next time the publisher web app (rxservices.war) it tries to get a connection from the connection pool, it needs to create a new one, and since that request is coming from the rxservices webapp, it fails.

The correct method for database publishing is to create your own JNDI datasource file in the AppServer\server\rx\deploy directory, which must be a file ending with the “-ds.xml” suffix (e.g. “dbpub-ds.xml”). You can find examples in the AppServer\docs\examples\jca directory - you should create a local-tx-datasource.

The next product release will allow Rhythmyx datasources created with the Server Administrator to be used with database publishing.[/QUOTE]