JBossDeveloper

After making some headway (i thought) i have this up and running in a branch, however, after talking to Jesper he doesnt think what ive done is correct, the config i had was something like this:

<resource-adapter name="hornetq-ra">

                <connectors>

                    <!--<in-vm-connector name="in-vm-ra" server-id="0"/>-->

                    <netty-connector name="remote-ra" socket-binding="messaging"/>

                </connectors>

                <param key="useLocalTx" value="false"/>

                <param key="userName" value="guest"/>

                <param key="password" value="guest"/>

                <connection-factory name="RAConnectionFactory">

                    <entries>

                        <entry name="java:/JmsXA"/>

                    </entries>

                </connection-factory>

                <connection-factory name="RemoteRAConnectionFactory">

                    <!--override the connectors-->

                    <connectors>

                        <connector-ref connector-name="netty"/>

                    </connectors>

                    <entries>

                        <entry name="java:/RemoteJmsXA"/>

                    </entries>

                </connection-factory>

            </resource-adapter>

This is a typical scenario that users want and we ahip examples showing this in AS5 etc, so it seems to make sense to me.

When someone comes up with a schema defining what they want me to do i will pick this up again, until then I'll be working on other important hornetq stuff.

Do we have MDBs working already? Or we need Carlo to do anything in top of this?

Well mdb is broken at the minute so i dont kbow if it actually works, altho the RA does deploy ok. I need to add some remove and describe stuff but thats about it.

 

What Jesper is complaining about?

Jesper isnt complaining, he just has a different view on how the config should be to me. As we discussed in the meeting last week, it should be as simple to deploy a RA cf as a normal cf, however the way jacamar works you need to deploy the all the cf's associated with the ra as part of the ra config which is not how i envisaged.

Andy Taylor wrote:

 

After making some headway (i thought) i have this up and running in a branch, however, after talking to Jesper he doesnt think what ive done is correct, the config i had was something like this:

This is a typical scenario that users want and we ahip examples showing this in AS5 etc, so it seems to make sense to me.

- snip -

When someone comes up with a schema defining what they want me to do i will pick this up again, until then I'll be working on other important hornetq stuff.

First off, thanks for making some major progress on this.

One of the things we talked about last week was simplifying our configuration so that the user doesn't have to declare a bunch of internal wiring details. E.g we declare a queue, indicate whether or not its jms, and provide things like a connectionfactory jndi name. From this we can automatically (programticallly) construct a resource adapter (which ultimately the user doesn't care about). I think we all agreed this would be the most user friendly approach, but you guys brought up that you wanted to break it into steps, just to get mdbs working as a first step and then the usability changes as a second step. This was/is fine with me, as long as we end up with the final solution in 7 CR1. So if this is the first step phase, then I don't see why we are arguing about the schema. My guess is the issue is that Jesper wasn't in that conversation, and so that added some confusion to all of this. Sorry about that.

There are some EAP requirements we have to meet with whatever the final approach is though, which jesper might have been referring to (not sure since I didnt see the conversation):

1. The configuration should only contain user configuration items (no internal wiring like class names etc, unless they point to a user's class)
2. Everything that we intend to maintain compatiblity for, and that we expect the user to use should be a schema element or attribute. This is so xml editors can be used to tab complete values etc.
3. Everything configurable in XML must be configurable via the management APIs
4. Anything that is not backwards compat, say experimental or a support only flag, should be a property.
5. All network interface and port values must be tied to the socket binding system
6. If at all possible there should be some style consistency between subsystems (this one is sometimes easier said than done)

Let's chat on irc about where things are tomorrow, and how we can help.

Thanks!

BTW to avoid further confusion how about I come up with a schema/config proposal? Then you guys can ridicule it until we get it right

well why dont we start with my suggestion and why its not appropriate

From what I understand...  we can just commit what you have now.. and we can change things (evolve thing) later with a bit more guidance from Jason.

i dont think we should commit anything until we have something that works

So after reviewing the schemas the example below is what I think would be user friendly yet still true to the hq concepts, and offer the same level of configurability.

Some notes about this

1. This is an example of using one subsystem instead of two (the route we all wanted to go)
2. No resource adaptor block, the connection factory config should contain everything we need to generate one behind the scenes
3. Removing content value elements makes the configuration more concise and consitent with the rest of AS
4. Usage of properties for stable/expected/bc user configuration is converted to typed structures in schema as required by our EAP6 requirements
5. After reviewing the hq schemas I have to say I agree now that jms queues and core queues need to be expressed differently, since they allow different types of configuration.

<subsystem xmlns="urn:jboss:domain:hornetq:1.0">
   <acceptors>
      <in-vm-acceptor name="in-vm" server-id="0"/>
      <netty-acceptor name="netty" socket-binding="hornetq"/>
      <netty-acceptor name="netty-throughput" socket-binding="hornetq-throughput"
                      batch-delay="50" direct-deliver="false"/>
   </acceptors>
   <connectors>
      <in-vm-connector name="in-vm" server-id="0"/>
      <netty-connector name="netty" socket-binding="hornetq"/>
      <netty-connector name="netty-throughput" socket-binding="hornetq-throughput"
                       batch-delay="50"/>
   </connectors>

   <connection-factories>
     <connection-factory name="InVMConnectionFactory">
        <connector name="in-vm" backup="netty"/>
        <jndi-binding name="java:/jboss/jms/ConnectionFactory"/>
      </connection-factory>
      <connection-factory name="RemoteConnectionFactory">
         <connector name="netty" backup="in-vm"/>
         <jndi-binding name="java:/jboss/jms/RemoteConnectionFactory"/>
      </connection-factory>
      <connection-factory name="RemoteXAConnectionFactory">
         <connector name="netty" backup="in-vm"/>
         <transaction mode="xa"/>
         <jndi-binding name="java:/jboss/jms/RemoteXAConnectionFactory"/>
      </connection-factory>
   </connection-factories>
   <address-settings> 
      <address-setting match="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue"
                                 redelivery-delay="0" max-size-bytes="10485760" message-counter-history-day-limit="10"
                                 address-full-policy="BLOCK"/>
   </address-settings>

   <core-queues>
       <core-queue name="coreQueue"/>
   </core-queues>

   <jms-destinations>
      <jms-queue name="testQueue">
        <jndi-binding name="queue/test"/>
      </jms-queue>
      <jms-topic name="testTopic">
        <jndi-binding name="topic/test"/>
      </jms-topic>
   </jms-destinations>

   <journal type="NIO" size="102400"/>
   <persistence enabled="false"/>
</subsystem>

Yes, i agree with Clebert, there has to be a resource adapter configured somewhere, the resource adapter is the config for the incoming plus the default config for any cf's created using it. 1 ra = 1 incoming and n outgoing. There has to be an RA configured. Also there is only 1 RA service deployed per RA and its cf's, so these have to be deployed at the same time other wise you have 1 RA per cf which i don't think is correct.

Andy Taylor wrote:

 

Yes, i agree with Clebert, there has to be a resource adapter configured somewhere, the resource adapter is the config for the incoming plus the default config for any cf's created using it. 1 ra = 1 incoming and n outgoing. There has to be an RA configured. Also there is only 1 RA service deployed per RA and its cf's, so these have to be deployed at the same time other wise you have 1 RA per cf which i don't think is correct.

Just to make sure I chatted with Jesper briefly about the drawbacks to 1 RA Service per 1 CF, and he said there really isnt any difference. The only reason to have multiple connection factories under the same resource is to share configuration. Basically what I am after here is that we look at this from a user perspective, come up with something thats at least as easy to use as our competitors, and then figure out how to map the impl details to that instead of the other way around.

Just to make sure I chatted with Jesper briefly about the drawbacks to 1 RA Service per 1 CF, and he said there really isnt any difference. The only reason to have multiple connection factories under the same resource is to share configuration. Basically what I am after here is that we look at this from a user perspective, come up with something thats at least as easy to use as our competitors, and then figure out how to map the impl details to that instead of the other way around.

from a user perspective there are 2 types, those who don't know and don't care about this and will never change the configuration any way and those who understand how resource adapters work and configured and expect it to be done like this. I think thet there *should* be a notion of configuring a resource adapter as we do now, serious messaging users expect this. I dont think we should over simplify the configuration just because 95% of users don't understand it and wouldnt change it anyway.

As far as our competitors, all the RA's i have configured have been very similar.