JBossDeveloper

Hi Tim,

Here is the login-config.xml file.

<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
"-//JBoss//DTD JBOSS Security Config 3.0//EN"
"http://www.jboss.org/j2ee/dtd/security_config.dtd">

<!-- The XML based JAAS login configuration read by the
org.jboss.security.auth.login.XMLLoginConfig mbean. Add
an application-policy element for each security domain.

The outline of the application-policy is:
<application-policy name="security-domain-name">

<login-module code="login.module1.class.name" flag="control_flag">
<module-option name = "option1-name">option1-value</module-option>
<module-option name = "option2-name">option2-value</module-option>
...
</login-module>

<login-module code="login.module2.class.name" flag="control_flag">
...
</login-module>
...

</application-policy>

$Revision: 1.12.2.5 $
-->



<application-policy name = "messaging">

<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" >
<module-option name = "unauthenticatedIdentity">guest</module-option>
<module-option name = "usersProperties">messaging-users.properties</module-option>
<module-option name = "rolesProperties">messaging-roles.properties</module-option>
</login-module>

</application-policy>

<!-- Used by clients within the application server VM such as
mbeans and servlets that access EJBs.
-->
<application-policy name = "client-login">

<login-module code = "org.jboss.security.ClientLoginModule"
flag = "required">
<!-- Any existing security context will be restored on logout -->
<module-option name="restore-login-identity">true</module-option>
</login-module>

</application-policy>

<!-- Security domain for JBossMQ -->
<application-policy name = "jbossmq">

<login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
flag = "required">
<module-option name = "unauthenticatedIdentity">guest</module-option>
<module-option name = "dsJndiName">java:/DefaultDS</module-option>
<module-option name = "principalsQuery">SELECT PASSWD FROM JMS_USERS WHERE USERID=?</module-option>
<module-option name = "rolesQuery">SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?</module-option>
</login-module>

</application-policy>

<!-- Security domain for JBossMQ when using file-state-service.xml
<application-policy name = "jbossmq">

<login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
flag = "required">
<module-option name = "unauthenticatedIdentity">guest</module-option>
<module-option name = "sm.objectname">jboss.mq:service=StateManager</module-option>
</login-module>

</application-policy>
-->

<!-- Security domains for testing new jca framework -->
<application-policy name = "HsqlDbRealm">

<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">sa</module-option>
<module-option name = "userName">sa</module-option>
<module-option name = "password"></module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
</login-module>

</application-policy>

<application-policy name = "JmsXARealm">

<login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
flag = "required">
<module-option name = "principal">guest</module-option>
<module-option name = "userName">guest</module-option>
<module-option name = "password">guest</module-option>
<module-option name = "managedConnectionFactoryName">jboss.jca:service=TxCM,name=JmsXA</module-option>
</login-module>

</application-policy>

<!-- A template configuration for the jmx-console web application. This
defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "jmx-console">

<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>

</application-policy>

<!-- A template configuration for the web-console web application. This
defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name = "web-console">

<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">web-console-users.properties</module-option>
<module-option name="rolesProperties">web-console-roles.properties</module-option>
</login-module>

</application-policy>

<!--
A template configuration for the JBossWS security domain.
This defaults to the UsersRolesLoginModule the same as other and should be
changed to a stronger authentication mechanism as required.
-->
<application-policy name="JBossWS">

<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag="required">
<module-option name="usersProperties">props/jbossws-users.properties</module-option>
<module-option name="rolesProperties">props/jbossws-roles.properties</module-option>
<module-option name="unauthenticatedIdentity">anonymous</module-option>
</login-module>

</application-policy>

<!-- The default login configuration used by any security domain that
does not have a application-policy entry with a matching name
-->
<application-policy name = "other">
<!-- A simple server login module, which can be used when the number
of users is relatively small. It uses two properties files:
users.properties, which holds users (key) and their password (value).
roles.properties, which holds users (key) and a comma-separated list of
their roles (value).
The unauthenticatedIdentity property defines the name of the principal
that will be used when a null username and password are presented as is
the case for an unuathenticated web client or MDB. If you want to
allow such users to be authenticated add the property, e.g.,
unauthenticatedIdentity="nobody"
-->

<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" />

</application-policy>




Thanks,

Dennis

Tim,

I changed the login-config.xml file and now the other domain section looks like this:


<application-policy name = "other">
<!-- A simple server login module, which can be used when the number
of users is relatively small. It uses two properties files:
users.properties, which holds users (key) and their password (value).
roles.properties, which holds users (key) and a comma-separated list of
their roles (value).
The unauthenticatedIdentity property defines the name of the principal
that will be used when a null username and password are presented as is
the case for an unuathenticated web client or MDB. If you want to
allow such users to be authenticated add the property, e.g.,
unauthenticatedIdentity="nobody"
-->

<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule" flag = "required">
<module-option name="unauthenticatedIdentity">guest</module-option>
</login-module>

</application-policy>


It will take me about an hour to test it since the exception only occurs after the system has been idle for about 30 minutes.

Thanks for your help,

Dennis

Tim,

No change. I still get the same exception.

Dennis

Tim,

No.


2006-06-26 13:50:32,593 WARN [org.jboss.jms.client.JBossConnectionConsumer] Connection consumer closing due to error in listening thread JBossConnectionConsumer[-2147483628, 1]
javax.jms.JMSSecurityException: User null is NOT authenticated
at org.jboss.jms.server.security.SecurityMetadataStore.authenticate(SecurityMetadataStore.java:181)
at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:252)
at org.jboss.jms.server.container.SecurityAspect.checkConsumerAccess(SecurityAspect.java:174)
at org.jboss.jms.server.container.SecurityAspect.handleGetMessageNow(SecurityAspect.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Dennis

Tim,

QUEUE ALWAYS DIES AFTER 30 MINUTES!

I tried using the preconfigured testQueue and A queues for the reponse queue - same exceptions. Then I started the server and used a keep-alive jsp to hit the server every 10 seconds. After 30 minutes (everytime) the server threw the following exception:


2006-06-26 22:17:57,640 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] Failed to load users/passwords/role files
java.io.IOException: No properties file: messaging-users.properties or defaults: defaultUsers.properties found
at org.jboss.security.auth.spi.Util.loadProperties(Util.java:313)
at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:662)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)
at javax.security.auth.login.LoginContext.login(LoginContext.java:534)
at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:601)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:535)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:344)
at org.jboss.jms.server.security.SecurityMetadataStore.authenticate(SecurityMetadataStore.java:174)
at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:252)
at org.jboss.jms.server.container.SecurityAspect.checkConsumerAccess(SecurityAspect.java:174)
at org.jboss.jms.server.container.SecurityAspect.handleGetMessageNow(SecurityAspect.java:155)
at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:130)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:842)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:82)
at org.jboss.remoting.Client.invoke(Client.java:610)
at org.jboss.remoting.Client.invoke(Client.java:602)
at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$getMessageNow_5405025797982928611.invokeNext(ClientConsumerDelegate$getMessageNow_5405025797982928611.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$getMessageNow_5405025797982928611.invokeNext(ClientConsumerDelegate$getMessageNow_5405025797982928611.java)
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$getMessageNow_5405025797982928611.invokeNext(ClientConsumerDelegate$getMessageNow_5405025797982928611.java)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientConsumerDelegate$getMessageNow_5405025797982928611.invokeNext(ClientConsumerDelegate$getMessageNow_5405025797982928611.java)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.getMessageNow(ClientConsumerDelegate.java)
at org.jboss.jms.client.remoting.MessageCallbackHandler$ConsumerActivationRunnable.run(MessageCallbackHandler.java:781)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:534)

Any ideas?

Dennis

Tim,

The machine is not running out of memory and I am not sending messages faster than I can comsume them.

I can send messages every 2 minutes or every ten minutes and at 30 minutes I will get that exception. It is always 30 minutes - not 28 or 33.

It sounds like some lease expires and the system fails when it tries to renew it.

Thanks,

Dennis

Tim,

Sounds lika a good idea.

Let me see if I can disable the code that accesses other systems so that it is self contained.

Thanks,

Dennis

Tim,

It looks like I 'fixed' the problem.

I copied the messaging-users.properties and messaging-roles.properties files into the:

\server\messaging
\server\messaging\conf
\server\messaging\conf\props

directories.

The keep-alive jsp has been running for over an hour.

Over the next day or two I will determine which directory it is looking into to find these files.

Thanks for your help,

Dennis