Auto-discovery

[jaink]

Can Jboss messaging clients auto discover the JMS Server? If so how is that configured.

Thanks for the help.

[ovidiu.feodorov]

I don't exactly understand your question.

A JMS client needs to look up a ConnectionFactory in JNDI and use that to connect to the server.

Now, how the client discovers the JNDI server it's a different story and has nothing to do with Messaging. JBoss Naming has a feature called "naming discover" that uses multicast for server discovery.

http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch3.chapter.html#d0e7449

[jaink]

I thought JBoss Messaging can operate in standalone mode, not requiring a application server. Do a need a JNDI server to look up the connection factory for a client to connect to a JBOss Messaging server?

[ovidiu.feodorov]

Yes, this is how it currently works. The JNDI server doesn't need to be the JBoss Naming, but a JNDI server is required.

We can talk dependency injection and other things, but these are not yet available.

[ovidiu.feodorov]

Let's try something else: what are you trying to do?

[jaink]

We need a light weight JMS implementation which can work in a standalone mode not requiring application server or a JNDI server. We also need the JMS clients to auto-discover the JMS server. So, just to understand this better it looks like JBoss Messaging needs to be embedded in some app server? Is that correct?

[ovidiu.feodorov]

Yes, for the time being.
However, what you suggested is the direction we're going.
See http://www.jboss.org/index.html?module=bb&op=viewtopic&t=80627
http://jira.jboss.org/jira/browse/JBMESSAGING-25

[jaink]

Thanks. I understand that JBoss is based on micro-kernal technology. So if we deploy AS + messaging , how big is a typical footprint and may be we need to just try it out.

[ovidiu.feodorov]

The 1.0.1.CR1 that will go out today (hopefully) includes a release management script that creates a slimmed down microkernel deployment based on 4.0.3SP1, which only contains the transitive closure of the Messaging dependencies, plust Tomcat for management (JMX console).

To generate that configuration, just set JBOSS_HOME to a JBoss 4.0.3SP1 installation and

cd util
ant -f release-admin.xml standalone

You'll get an idea of how big the footprint is.

However, as I said, we're moving towards microcontainer support, so soon you'll also have that choice.

[mwaschkowski]

Hi Ovidiu,

"You'll get an idea of how big the footprint is. "

Can you clarify this a bit? I'm not sure of what the minimum's in terms of memory would be for this slimmed down config. Would it operate in 32M or 64M or somewhere in between?

Thanks,

Mark

[ovidiu.feodorov]

The "default" JBoss 4.0.3SP1 configuration is somewhere around 30MB. I haven't measured the slimmed down version, yet.

But then it's up to you to configure the heap size depending of your application behavioral patterns, since you want to keep non-persistent messages in memory as much as you can to prevent unnecessary message paging.

[mwaschkowski]

That means that you should be able to easily run the slimmed down version on 32MB, especially if all your queues are persistent.

Good to know, thanks.

Mark

[ovidiu.feodorov]

Yes, I actually expect a much lower figure than that.

You can bring the footprint down even further by getting rid of Tomcat (and implicitely jmx-console). You can still manage your server using twiddle or programatically

[timfox]

Whether your messages are persistent are not has no bearing on how many messages are stored in memory.

This is controlled by the fullSize parameter on the queue and applies equally to persistent and non persistent messages.