Spring Boot Admin 2.0.0 Eureka 1.9.2 Not Displaying Any Apps - spring-boot-admin

I have 3 apps running and registered in the Eureka server, when I go to http://localhost:8761/eureka/apps I can see them all:
<applications>
<versions__delta>1</versions__delta>
<apps__hashcode>UP_3_</apps__hashcode>
<application>
<name>ARSIICLOUD-SERVER</name>
<instance>
<instanceId>arsiicloud-server</instanceId>
<hostName>localhost</hostName>
<app>ARSIICLOUD-SERVER</app>
<ipAddr>10.34.2.105</ipAddr>
<status>UP</status>
<overriddenstatus>UNKNOWN</overriddenstatus>
<port enabled="true">8761</port>
<securePort enabled="false">443</securePort>
<countryId>1</countryId>
<dataCenterInfo class="com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo">
<name>MyOwn</name>
</dataCenterInfo>
<leaseInfo>
<renewalIntervalInSecs>10</renewalIntervalInSecs>
<durationInSecs>90</durationInSecs>
<registrationTimestamp>1528307815989</registrationTimestamp>
<lastRenewalTimestamp>1528308446108</lastRenewalTimestamp>
<evictionTimestamp>0</evictionTimestamp>
<serviceUpTimestamp>1528307786859</serviceUpTimestamp>
</leaseInfo>
<metadata>
<management.context-path>/manage</management.context-path>
<management.port>8761</management.port>
<configPath>/config</configPath>
</metadata>
<homePageUrl>http://localhost:8761/</homePageUrl>
<statusPageUrl>http://localhost:8761/manage/info</statusPageUrl>
<healthCheckUrl>http://localhost:8761/manage/health</healthCheckUrl>
<vipAddress>arsiicloud-server</vipAddress>
<secureVipAddress>arsiicloud-server</secureVipAddress>
<isCoordinatingDiscoveryServer>true</isCoordinatingDiscoveryServer>
<lastUpdatedTimestamp>1528307815989</lastUpdatedTimestamp>
<lastDirtyTimestamp>1528307785964</lastDirtyTimestamp>
<actionType>ADDED</actionType>
</instance>
</application>
<application>
<name>ARSIICLOUD-CLIENT</name>
<instance>
<instanceId>arsiicloud-client</instanceId>
<hostName>localhost</hostName>
<app>ARSIICLOUD-CLIENT</app>
<ipAddr>10.34.2.105</ipAddr>
<status>UP</status>
<overriddenstatus>UNKNOWN</overriddenstatus>
<port enabled="true">7777</port>
<securePort enabled="false">443</securePort>
<countryId>1</countryId>
<dataCenterInfo class="com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo">
<name>MyOwn</name>
</dataCenterInfo>
<leaseInfo>
<renewalIntervalInSecs>10</renewalIntervalInSecs>
<durationInSecs>90</durationInSecs>
<registrationTimestamp>1528308331840</registrationTimestamp>
<lastRenewalTimestamp>1528308441830</lastRenewalTimestamp>
<evictionTimestamp>0</evictionTimestamp>
<serviceUpTimestamp>1528308331840</serviceUpTimestamp>
</leaseInfo>
<metadata>
<management.context-path>/manage</management.context-path>
<management.port>7777</management.port>
</metadata>
<homePageUrl>http://localhost:7777/</homePageUrl>
<statusPageUrl>http://localhost:7777/manage/info</statusPageUrl>
<healthCheckUrl>http://localhost:7777/manage/health</healthCheckUrl>
<vipAddress>arsiicloud-client</vipAddress>
<secureVipAddress>arsiicloud-client</secureVipAddress>
<isCoordinatingDiscoveryServer>false</isCoordinatingDiscoveryServer>
<lastUpdatedTimestamp>1528308331840</lastUpdatedTimestamp>
<lastDirtyTimestamp>1528308331813</lastDirtyTimestamp>
<actionType>ADDED</actionType>
</instance>
</application>
<application>
<name>ARSIICLOUD-ADMIN</name>
<instance>
<instanceId>arsiicloud-admin</instanceId>
<hostName>localhost</hostName>
<app>ARSIICLOUD-ADMIN</app>
<ipAddr>10.34.2.105</ipAddr>
<status>UP</status>
<overriddenstatus>UNKNOWN</overriddenstatus>
<port enabled="true">8888</port>
<securePort enabled="false">443</securePort>
<countryId>1</countryId>
<dataCenterInfo class="com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo">
<name>MyOwn</name>
</dataCenterInfo>
<leaseInfo>
<renewalIntervalInSecs>10</renewalIntervalInSecs>
<durationInSecs>90</durationInSecs>
<registrationTimestamp>1528308338880</registrationTimestamp>
<lastRenewalTimestamp>1528308448999</lastRenewalTimestamp>
<evictionTimestamp>0</evictionTimestamp>
<serviceUpTimestamp>1528307793010</serviceUpTimestamp>
</leaseInfo>
<metadata>
<management.context-path>/manage</management.context-path>
<management.port>8888</management.port>
</metadata>
<homePageUrl>http://localhost:8888/</homePageUrl>
<statusPageUrl>http://localhost:8888/manage/info</statusPageUrl>
<healthCheckUrl>http://localhost:8888/manage/health</healthCheckUrl>
<vipAddress>arsiicloud-admin</vipAddress>
<secureVipAddress>arsiicloud-admin</secureVipAddress>
<isCoordinatingDiscoveryServer>false</isCoordinatingDiscoveryServer>
<lastUpdatedTimestamp>1528308338880</lastUpdatedTimestamp>
<lastDirtyTimestamp>1528308338844</lastDirtyTimestamp>
<actionType>ADDED</actionType>
</instance>
</application>
</applications>
The issue is that when I check the Spring Boot Admin web page it appears empty:
Activating the trace log for StatusUpdateTrigger and DiscoveryClient I can see that DiscoveryClient is successfully retrieving the apps info but for some reason they are not reflected in Spring Boot Admin:
de.codecentric.boot.admin.server.services.StatusUpdateTrigger trace onNext(3)
de.codecentric.boot.admin.server.services.StatusUpdateTrigger updateStatusForAllInstances Updating status for all instances
de.codecentric.boot.admin.server.services.StatusUpdateTrigger trace request(1)
com.netflix.discovery.DiscoveryClient renew DiscoveryClient_ARSIICLOUD-ADMIN/arsiicloud-admin - Heartbeat status: 200
com.netflix.discovery.DiscoveryClient getAndUpdateDelta Got delta update with apps hashcode UP_3_
com.netflix.discovery.DiscoveryClient updateDelta Added instance arsiicloud-client to the existing apps in region null
com.netflix.discovery.DiscoveryClient updateDelta Added instance arsiicloud-admin to the existing apps in region null
com.netflix.discovery.DiscoveryClient updateDelta The total number of instances fetched by the delta processor : 2
com.netflix.discovery.DiscoveryClient logTotalInstances The total number of all instances in the client now is 3
com.netflix.discovery.DiscoveryClient refreshRegistry Completed cache refresh task for discovery. All Apps hash code is Local region apps hashcode: UP_3_, is fetching remote regions? false
com.netflix.discovery.DiscoveryClient getAndUpdateDelta Got delta update with apps hashcode UP_3_
com.netflix.discovery.DiscoveryClient updateDelta Added instance arsiicloud-client to the existing apps in region null
com.netflix.discovery.DiscoveryClient updateDelta Added instance arsiicloud-admin to the existing apps in region null
com.netflix.discovery.DiscoveryClient updateDelta The total number of instances fetched by the delta processor : 2
com.netflix.discovery.DiscoveryClient logTotalInstances The total number of all instances in the client now is 3
com.netflix.discovery.DiscoveryClient refreshRegistry Completed cache refresh task for discovery. All Apps hash code is Local region apps hashcode: UP_3_, is fetching remote regions? false
Any idea of what is wrong?
Thanks!
Johann

I ran into the same problem. I was able to fix by upgrading the admin server to the 2.0.1-snapshot
so add
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-starter-server</artifactId>
<version>2.0.1-SNAPSHOT</version>
</dependency>
Then also add the snapshot repo
<repositories>
<repository>
<id>sonatype-nexus-snapshots</id>
<snapshots>
<enabled>true</enabled>
</snapshots>
<url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</repository>
</repositories>

Related

Ehcache jgroup replication issue [FIND_INITIAL_MBRS FIND_MBRS ] are required by GMS, but not provided

Our project moved from tradition tomcat deployment to kubernetes just now. Previously, Ehache replication was working using RMI Replicator. RMI relication is also now not working with Kubernetes so I am trying to replicate ehcache kubernetes using jroups. Without using kubernetes everything is working but during deployment I am getting below log.
I ma using K3s and application is in springboot.
I have followed this tutorial
https://github.com/kunal-bhatia/ehcache-jgroups-demo
ERROR n.s.e.d.j.JGroupsCacheManagerPeerProvider:140 - Failed to create JGroups Channel, replication will not function. JGroups properties:
null
java.lang.Exception: events [FIND_INITIAL_MBRS FIND_MBRS ] are required by GMS, but not provided by any of the protocols below it
at org.jgroups.stack.Configurator.sanityCheck(Configurator.java:503)
at org.jgroups.stack.Configurator.connectProtocols(Configurator.java:223)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:123)
at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:476)
at org.jgroups.JChannel.init(JChannel.java:852)
tcp.xml file
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:org:jgroups"
xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
<TCP
bind_addr="match-interface:eth0,match-interface:lo"
bind_port="7810"
recv_buf_size="5M"
send_buf_size="1M"
max_bundle_size="64K"
enable_diagnostics="true"
thread_naming_pattern="cl"
thread_pool.min_threads="0"
thread_pool.max_threads="500"
thread_pool.keep_alive_time="30000"/>
<org.jgroups.protocols.kubernetes.KUBE_PING
namespace="${KUBE_NAMESPACE:ehcache-demo}"/>
<MERGE3 max_interval="30000"
min_interval="10000"/>
<VERIFY_SUSPECT timeout="1500"/>
<BARRIER/>
<pbcast.NAKACK2 xmit_interval="500"
xmit_table_num_rows="100"
xmit_table_msgs_per_row="2000"
xmit_table_max_compaction_time="30000"
use_mcast_xmit="false"
discard_delivered_msgs="true"/>
<UNICAST3
xmit_table_num_rows="100"
xmit_table_msgs_per_row="1000"
xmit_table_max_compaction_time="30000"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="8m"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000"
view_bundling="true"/>
<MFC max_credits="2M"
min_threshold="0.4"/>
<FRAG2 frag_size="60K"/>
<pbcast.STATE_TRANSFER/>
<CENTRAL_LOCK/>
<COUNTER/>
</config>

eReviewBoard can't raise review request

I have my reviewboard 1.7 configured and I am using eReviewBoard and Subclipse plugins in Eclipse IDE.
The issue is when I try to raise the review request it fails giving "timed out" as "Failed creating new review request : Exception executing PutMethod on http://10.203.3.244/api/review-requests/380/draft/ : Read timed out"
When I checked the info at "http://10.203.3.244/api/review-requests/380" I can't find the PUT method for "http://10.203.3.244/api/review-requests/380/draft" instead it is only for "http://10.203.3.244/api/review-requests/380"
Below is the xml:
<?xml version="1.0" encoding="utf-8"?>
<rsp>
<stat>ok</stat>
<review_request>
<status>pending</status>
<last_updated>2014-01-22T07:38:34Z</last_updated>
<description>Testing... </description>
<links>
<diffs>
<href>http://10.203.3.244/api/review-requests/380/diffs/</href>
<method>GET</method>
</diffs>
<repository>
<href>http://10.203.3.244/api/repositories/3/</href>
<method>GET</method>
<title>M2M Repository</title>
</repository>
<screenshots>
<href>http://10.203.3.244/api/review-requests/380/screenshots/</href>
<method>GET</method>
</screenshots>
<self>
<href>http://10.203.3.244/api/review-requests/380/</href>
<method>GET</method>
</self>
<update>
<href>http://10.203.3.244/api/review-requests/380/</href>
<method>PUT</method>
</update>
<last_update>
<href>http://10.203.3.244/api/review-requests/380/last-update/</href>
<method>GET</method>
</last_update>
<reviews>
<href>http://10.203.3.244/api/review-requests/380/reviews/</href>
<method>GET</method>
</reviews>
<draft>
<href>http://10.203.3.244/api/review-requests/380/draft/</href>
<method>GET</method>
</draft>
<file_attachments>
<href>http://10.203.3.244/api/review-requests/380/file-attachments/</href>
<method>GET</method>
</file_attachments>
<submitter>
<href>http://10.203.3.244/api/users/amritpal/</href>
<method>GET</method>
<title>amritpal</title>
</submitter>
<changes>
<href>http://10.203.3.244/api/review-requests/380/changes/</href>
<method>GET</method>
</changes>
<delete>
<href>http://10.203.3.244/api/review-requests/380/</href>
<method>DELETE</method>
</delete>
</links>
I don't know what to do next. I understand this info is generated and read by the plugin itself??!!
Has anyone faced this issue?
It looks like you raised this issue with the project, which is what I was going to recommend you do:
https://github.com/rombert/ereviewboard/issues/129

Transaction commit delay when routing message from one jms queue to another

We are trying to build simple transacted jms-to-jms router using Mule ESB and JBoss Messaging. When we run Mule ESB with application configured as below, we observe strange behaviour.
Approximately 10 messages are routed from queue test1 to test2
Nothing happens for ~40 seconds.
goto 1
Queue test1 is filled with around 500 messages when we start test. We use Mule 3.2 and JBoss 5.1.
If I remove transactions from code below everything works fine, all messages are sent to queue test2 instantly. Also, everything is fine if I change transactions from xa to jms -- by replacing xa-transaction tags with jms:transaction.
I don't know what causes this pause in message processing on ESB, probably transaction commit is delayed.
My question is: what should I do to have xa transactions working correctly?
I'll provide more details if needed. I asked this question on Mule ESB forum before with no answer http://forum.mulesoft.org/mulesoft/topics/transaction_commit_delay_when_routing_message_from_one_jms_queue_to_another
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:jms="http://www.mulesoft.org/schema/mule/jms" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:core="http://www.mulesoft.org/schema/mule/core" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jbossts="http://www.mulesoft.org/schema/mule/jbossts" version="CE-3.2.1" xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/jms http://www.mulesoft.org/schema/mule/jms/current/mule-jms.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/jbossts http://www.mulesoft.org/schema/mule/jbossts/current/mule-jbossts.xsd ">
<jbossts:transaction-manager> </jbossts:transaction-manager>
<configuration>
<default-threading-profile maxThreadsActive="30" maxThreadsIdle="5"/>
<default-receiver-threading-profile maxThreadsActive="10" maxThreadsIdle="5"/>
</configuration>
<spring:beans>
<spring:bean id="jmsJndiTemplate" class="org.springframework.jndi.JndiTemplate" doc:name="Bean">
<spring:property name="environment">
<spring:props>
<spring:prop key="java.naming.factory.url.pkgs">org.jboss.naming:org.jnp.interfaces</spring:prop>
<spring:prop key="jnp.disableDiscovery">true</spring:prop>
<spring:prop key="java.naming.factory.initial">org.jnp.interfaces.NamingContextFactory</spring:prop>
<spring:prop key="java.naming.provider.url">localhost:1099</spring:prop>
</spring:props>
</spring:property>
</spring:bean>
<spring:bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean" doc:name="Bean">
<spring:property name="jndiTemplate">
<spring:ref bean="jmsJndiTemplate"/>
</spring:property>
<spring:property name="jndiName">
<spring:value>XAConnectionFactory</spring:value>
</spring:property>
</spring:bean>
</spring:beans>
<jms:connector name="JMS" specification="1.1" numberOfConsumers="10" connectionFactory-ref="jmsConnectionFactory" doc:name="JMS"/>
<flow name="flow" doc:name="flow">
<jms:inbound-endpoint queue="test1" connector-ref="JMS" doc:name="qt1">
<xa-transaction action="ALWAYS_BEGIN"/>
</jms:inbound-endpoint>
<echo-component doc:name="Echo"/>
<jms:outbound-endpoint queue="test2" connector-ref="JMS" doc:name="qt2">
<xa-transaction action="ALWAYS_JOIN"/>
</jms:outbound-endpoint>
<echo-component doc:name="Echo"/>
</flow>
</mule>
Here you can find log fragment for 1 message interaction. Please note that in this case there was no delay.
And here is log fragment for 11 messages. All of them were in queue test1 when app started, as you can see 10 messages are routed instantly and one is delayed by 1 minute.
I've found root of my problem: my queues were defined with following attribute:
<attribute name="RedeliveryDelay">60000</attribute>
Removing it or setting low value solves my problem with delays. Problem is, I don't know why :)
I always thought that redelivery delay is used when delivery fails, which was not the case in my app.

jboss-esb fs-listener jbm message queue overflow

We have a jboss esb server which is reading files from the file system in a scheduled way (schedule frequency of 20sec) and convert them into the esb message then we parse the message.
There are some other providers/listeners (jms) and services configured on the esb servers. When there is an error in one of the services it effects the above process. File system provider (gateway) is working fine but the jms-listener who takes the gateway messages are not working and lots of messages are accumulated in the jbm queue (jbm_msg Oracle DB table).
Here is the problem, when my server is restarted messages in the jbm-queue is parsed in the esb for just 20 seconds which is the scheduled frequency of fs-provider, never process messages again and cpu usage goes up to 100% and stays there. We believe somehow fs-providers interrupts the jms-provider.
Is there any configuration we have been missing out.
Here are the configuration files that we have:
jboss-esb.xml
<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
<providers>
<fs-provider name="SitaIstProvider">
<fs-bus busid="gw_sita_ist" >
<fs-message-filter
directory="/ikarussita/IST/IN"
input-suffix=".RCV"
work-suffix=".lck"
post-delete="false"
post-directory="/ikarussita/IST/OK"
post-suffix=".ok"
error-delete="false"
error-directory="/ikarussita/IST/ERR"
error-suffix=".err"/>
</fs-bus>
</fs-provider>
<jms-provider name="SitaESBQueue" connection-factory="ConnectionFactory">
<jms-bus busid="esb_sita_queue">
<jms-message-filter dest-type="QUEUE" dest-name="queue/esb_sita_queue"/>
</jms-bus>
</jms-provider>
</providers>
<services>
<service category="SITA" name="SITA_IST" description="SITA Daemon For ISTCOXH">
<listeners>
<fs-listener name="Sita_Ist_Gateway" busidref="gw_sita_ist" is-gateway="true" schedule-frequency="20" />
<jms-listener name="Jms_Sita_EsbAware" busidref="esb_sita_queue" />
</listeners>
<actions mep="OneWay">
<action name="parse_msg" class="com.celebi.integration.action.sita.inbound.SitaHandler" process="parseMessage" />
<action name="send_ikarus" class="com.celebi.integration.action.ikarus.outbound.fis.FlightJmsSender" />
</actions>
</service>
</services>
</jbossesb>
jbm-queue-service.xml
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=esb_sita_queue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
<server>
deployment.xml
<jbossesb-deployment>
<depends>jboss.messaging.destination:service=Queue,name=esb_sita_queue</depends>
</jbossesb-deployment>
Thanx
Split the service into 2 separate services, one handling the JMS queue, the other the file poller. Specify the same action pipeline. That way you get the same functionality but without the threading issue. Also use max-threads attr on the listener to specify the number of reading threads.

How to configure startup sequence of JBoss services (JmsActivation)

When I deploy my application on JBoss 5 the EJBs are created before the QueueService is started. Creation of Message Driven beans now fails miserably because the queues are not yet available:
17:11:29,151 INFO [EJBContainer] STARTED EJB: .....
17:11:29,266 INFO [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:
..
..
17:11:29,928 WARN [JmsActivation] Failure in jms activation org.jboss.resource.adapter.jms.inflow.JmsActivationSpec#11694c ...
javax.naming.NameNotFoundException: ... not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
at org.jnp.server.NamingServer.lookup(NamingServer.java:399)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:722)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:682)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.util.naming.Util.lookup(Util.java:222)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDestination(JmsActivation.java:464)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:352)
at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:729)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:213)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
17:11:30,027 INFO [QueueService] Queue[/queue/....] started, fullSize=200000, pageSize=2000, downCacheSize=2000
How can the deploy sequence be configured?
Found the answer myself. I added the following annotation to the message driven bean:
#Depends({"jboss.messaging.destination:service=Topic,name=XxxxTopic"})
<?xml version="1.0" encoding="UTF-8"?>
<!--
Null persistence config.
Use this if you don't actually want to persist anything
$Id$
-->
<server>
<!-- Persistence Manager MBean configuration
======================================== -->
<mbean code="org.jboss.messaging.core.jmx.NullPersistenceManagerService"
name="jboss.messaging:service=PersistenceManager"
xmbean-dd="xmdesc/NullPersistenceManager-xmbean.xml"/>
<!-- Messaging Post Office MBean configuration
========================================= -->
<mbean code="org.jboss.messaging.core.jmx.MessagingPostOfficeService"
name="jboss.messaging:service=PostOffice"
xmbean-dd="xmdesc/MessagingPostOffice-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
<!-- The name of the post office -->
<attribute name="PostOfficeName">JMS post office</attribute>
<!-- This post office is clustered. If you don't want a clustered post office then set to false -->
<attribute name="Clustered">false</attribute>
</mbean>
<!-- Messaging JMS User Manager MBean config
======================================= -->
<mbean code="org.jboss.jms.server.plugin.JDBCJMSUserManagerService"
name="jboss.messaging:service=JMSUserManager"
xmbean-dd="xmdesc/JMSUserManager-xmbean.xml">
<depends optional-attribute-name="TransactionManager">jboss:service=TransactionManager</depends>
</mbean>
</server>
save this as 'null-persistence-service.xml' and put this deploy/messaging/
Now it will works