[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Routing ignoring page on first messages when in global s
by jmesnil
"clebert.suconic(a)jboss.com" wrote :
| I thought the management address won't have a queue, if there are no consumers.. what would mean messages are dropped on that case. (Right?)
|
Just a clarification as the management address behviour is quite particular.
There is no queue bound to the management address.
When a message is sent to the management address, it bypasses regular code path and is handled by the management service. A server message reply is created containing the management operation result and *this reply* is routed to the management message's reply-to.
The management message itself is never routed.
| private void handleManagementMessage(final ServerMessage message) throws Exception
| {
| ...
|
| ServerMessage reply = managementService.handleMessage(message);
|
| SimpleString replyTo = (SimpleString)message.getProperty(ClientMessageImpl.REPLYTO_HEADER_NAME);
|
| if (replyTo != null)
| {
| reply.setDestination(replyTo);
|
| send(reply);
| }
| }
|
The issue is that the reply message is paged and the management client will never receive the operation result.
In addition, when JMX is enabled, the MBean uses underneath the Core API to ensure management operations are replicated. This also means that, in that case, the server will always have a "management reply queue" so that the MBean can receive the operation result synchronously.
If we want the management to work transparently, we must not page messages send to "management reply" address (as I proposed in http://www.jboss.org/index.html?module=bb&op=viewtopic&t=159288&postdays=...).
If we do not want to treat the management case specifically, the user must configure the management reply address settings to disallow paging. But requiring explicit configuration for management reply address puts the burden on the user...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248469#4248469
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248469
16 years, 5 months
[Design of POJO Server] - Re: Deploying ValidatorFactory
by epbernard
"alesj" wrote : "epbernard" wrote :
| | What's the way to get that integrated?
| | The typical use case is one VF per application deployed. But we are discussing with Sun and the idea of one VF per module could have to be implemented (ie like JSR-299 and beans.xml)
| |
| This should be easy to do.
|
| 1) MC beanfactory to create us VF
| 2) VF Deployer that would push this properly into DeploymentUnit
| * what you do from here on is then up to other services, all they should care that this is available to them if the choose to use it
|
Do you know how things are push to JNDI, is that the deployer's responsibility?
anonymous wrote :
| If you point me to the location where you wanna impl this,
| I can have a crack at it, unless you are eager to do it yourself (as I know you haven't coded in 2years ;-)
|
I don't know the AS structure, where should such a code live on?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248452#4248452
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248452
16 years, 5 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Leaks in pinger when using manual reconnection?
by jmesnil
== Setup ==
* 1 single server (no backup)
* JMS Connection Factory configured with:
| <retry-interval>1000</retry-interval>
| <retry-interval-multiplier>1.0</retry-interval-multiplier>
| <reconnect-attempts>-1</reconnect-attempts>
| <failover-on-server-shutdown>true</failover-on-server-shutdown>
| <call-timeout>5000</call-timeout>
|
With this configuration, clients will try to reconnect indefinitely on the single server.
* One JMS ExceptionListener for manual reconnection:
| private ExceptionListener exceptionListener = new ExceptionListener()
| {
| public void onException(JMSException arg0)
| {
| System.out.println("TopicExample.onException()");
| disconnect();
| reconnect();
| }
| };
|
disconnect() closes the current JMS connection (if any)
reconnect() recreates all the JMS resources from JNDI
* The client registers a MessageListener (to print received messages) and send messages every 0.5s
I've added traces in the Pinger handlePacket() method to display when pings where received for which remoting connections.
== Steps ==
1. start the server
2. start the client
=> On the client, we create 2 remoting connections (1 when calling JMS cf.createConnection(), the other when calling JMS conn.createSession())
=> We receive pings for these 2 remoting connections
3. kills the server
=> On the client, the connection failure is detected:
| 6 aout 2009 13:29:57 org.jboss.messaging.core.logging.Logger warn
| ATTENTION: Connection failure has been detected The connection was closed by the server:5
| 6 aout 2009 13:29:57 org.jboss.messaging.core.logging.Logger warn
| ATTENTION: Connection failure has been detected The connection was closed by the server:5
|
4. Restart the server
=> On the client, we try to reattach the sessions to the servers. This code creates new RemotingConnections *and new Pingers*
| 6 ao?t 2009 13:30:28 org.jboss.messaging.core.logging.Logger warn
| ATTENTION: 9342944 Session not found on server when attempting to re-attach
| 6 ao?t 2009 13:30:28 org.jboss.messaging.core.logging.Logger warn
| ATTENTION: 11968595 Session not found on server when attempting to re-attach
|
5. Client's JMS ExceptionListener is called
=> when we try to close the current connection, it fails:
| javax.jms.JMSException: Timed out waiting for response when sending packet 74
| at org.jboss.messaging.core.remoting.impl.ChannelImpl.sendBlocking(ChannelImpl.java:328)
| at org.jboss.messaging.core.client.impl.ClientConsumerImpl.doCleanUp(ClientConsumerImpl.java:753)
| at org.jboss.messaging.core.client.impl.ClientConsumerImpl.close(ClientConsumerImpl.java:318)
| at org.jboss.messaging.jms.client.JBossMessageConsumer.close(JBossMessageConsumer.java:153)
| at org.jboss.messaging.jms.client.JBossSession.close(JBossSession.java:275)
| at org.jboss.messaging.jms.client.JBossConnection.close(JBossConnection.java:259)
| at org.jboss.jms.example.TopicExample.disconnect(TopicExample.java:112)
| at org.jboss.jms.example.TopicExample$2.onException(TopicExample.java:69)
| at org.jboss.messaging.jms.client.JBossConnection$JMSFailureListener.connectionFailed(JBossConnection.java:545)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callFailureListeners(RemotingConnectionImpl.java:402)
| at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:244)
| at org.jboss.messaging.core.client.impl.ConnectionManagerImpl$Channel0Handler$1.run(ConnectionManagerImpl.java:1119)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
| at java.lang.Thread.run(Thread.java:613)
| Caused by: MessagingException[errorCode=3 message=Timed out waiting for response when sending packet 74]
| ... 15 more
|
5b. Still in the JMS ExceptionListener, we reconnect to the Server starting from JNDI resources. This creates new RemotingConnections *and new Pingers*
6. The client can once again produce and consume messages
*but* the client receives pings for 4 connections!
It receives pings for the 2 remoting connections which were created when reconnecting.
But it also receives pings for the 2 remoting connections which were created when reattaching the session at step #4.
The exception at step #5 prevented the JMS connection to be closed properly, including closing its associated remoting connection(s) and its pinger(s)
If I kill/restart the server once more, I have now 6 pingers on the client.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4248442#4248442
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4248442
16 years, 5 months