1 2 3 4 5 6 Previous Next 82 Replies Latest reply: May 24, 2011 10:29 AM by Jason Greene Go to original post RSS
  • 60. Re: Resource Adapter integration on AS7
    Jason Greene Master

    Andy Taylor wrote:

     

    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.

    You can only oversimplify if you somehow eliminate or prevent something from being configured. In this case we are removing boilerplate junk that no one cares about.

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

    Strange, because all of the major vendors, I don't have to configure a resource adapter to use a jms queue. The only time you need to do that is to interop with some other thirdparty provider, so of course its less simple/elegant.

  • 61. Re: Resource Adapter integration on AS7
    Clebert Suconic Master

    We have to keep non-RA connection factories for HornetQ usages. We can't just make our ConnectionFactories through the resource adapter.

  • 62. Re: Resource Adapter integration on AS7
    Jason Greene Master

    Clebert Suconic wrote:

     

    We have to keep non-RA connection factories for HornetQ usages. We can't just make our ConnectionFactories through the resource adapter.

    What do the simple connection factories have that the RA ones do not? If someone configures a jms connection factory, and later decides they want to use an MDB, it should be easy to do. Is it performance perhaps?

     

    In any case that could either be an attribute on the connection-factory, or if they have incompatible configuration we could have two different element names to indicate the type.

  • 63. Re: Resource Adapter integration on AS7
    Clebert Suconic Master

    First: They don't have pools... Second they don't have all the Wrapper around JCA, Third they are supposedly faster...

     

     

    And we are not giving up them ;-)

     

     

    There's no way we are only going to offer RA connection factories.

  • 64. Re: Resource Adapter integration on AS7
    Clebert Suconic Master
    In any case that could either be an attribute on the connection-factory, or if they have incompatible configuration we could have two different element names to indicate the type

    What about the inbound?

     

     

    A type on the connection-factory could be acceptable, but what about the inbound for MDBs?

  • 65. Re: Resource Adapter integration on AS7
    Clebert Suconic Master

    Sorry, most importantly: The JCA Spec imposes certain restrictions like you're not supposed to create Listeners when using the JCA CF. There are probably others but this is the most important one.

  • 66. Re: Resource Adapter integration on AS7
    Clebert Suconic Master

     

    In any case that could either be an attribute on the connection-factory, or if they have incompatible configuration we could have two different element names to indicate the type.

     

     

    We would like to keep really clear it's a jca-connection-factory. We have lots of users using client connections factories without any JCA. Some are also using it inside the application server as we have a few extensions that are not exposed through JCA.

     

     

    @Andy: If that doesn't change much, make it at the same level as the connection factories.

     

    If you would have a lot of work to do around that, we can merge the ConnectionFactory and the JCAConnectionFactory later when we do the second phase as we agreed.

     

     

    We still don't know what to do with inBound on MDBs.

     

    @Andy: Again, if that will delay you.. just do it the way you're doing now and we can refactor it as part of the second phase.

  • 67. Re: Resource Adapter integration on AS7
    Andy Taylor Master
    In any case that could either be an attribute on the connection-factory, or if they have incompatible configuration we could have two different element names to indicate the type.

    Or we could just wrap the connection factory in the resource adapter configuration like i suggested, this means it is clearly identified as belonging to a resource adapter. We need the resource adapter config there as we need to specify how incoming connections are created, in your config i see no reference as to how to do this. Also it means the incoming and outrgoing share the same RA.

     

    With regard to Jesper's comment about there be no difference in creating a new RA for every cf i don't think this is true. We have done a lot of work with XA recently and had some optimisations that we were looking to do around this. basically a managed connection factory uses the Resource Adapter to create its connection factory, if this is a completely different RA instance then it ill be a new instance of the factory. This means that if there is a 2 branch xa transaction using the incoming and outgoing connections then the tm will use 2 phase commit, however it is possible, altho we hadnt changed it yet, that the same RA should return the same connection factory used for both which will allow the tm to optimize and use a 1 phase commit giving a marked improvement in performance.

  • 68. Resource Adapter integration on AS7
    Andy Taylor Master

    btw, with regard too this bit of your config

     

       <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>

     

    thats exactly how i had envisioned that to be when rolled into the main messaging module, so at least we are on the same page with something

  • 69. Resource Adapter integration on AS7
    jaikiran pai Master

    Out of curiosity, can a "core-queue" still be a target destination for a JMS message listener (like MDB)? In other words, does adding a core-queue also mean that it is a JMS destination?

  • 70. Resource Adapter integration on AS7
    Andy Taylor Master
    Out of curiosity, can a "core-queue" still be a target destination for a JMS message listener (like MDB)? In other words, does adding a core-queue also mean that it is a JMS destination?

    A JMS Queue = core queue with naming convention/jndi entry/jms queue mbean

     

    a topic subscription is also a core queue.

  • 71. Resource Adapter integration on AS7
    Jason Greene Master

    Andy Taylor wrote:

     

    In any case that could either be an attribute on the connection-factory, or if they have incompatible configuration we could have two different element names to indicate the type.

    Or we could just wrap the connection factory in the resource adapter configuration like i suggested, this means it is clearly identified as belonging to a resource adapter. We need the resource adapter config there as we need to specify how incoming connections are created, in your config i see no reference as to how to do this. Also it means the incoming and outrgoing share the same RA.

    Yeah that could be done just marking one of them as also handling inbound. As to forced sharing of outgoing & incoming it sounds like your next comment that that is what you want?

     

    With regard to Jesper's comment about there be no difference in creating a new RA for every cf i don't think this is true. We have done a lot of work with XA recently and had some optimisations that we were looking to do around this. basically a managed connection factory uses the Resource Adapter to create its connection factory, if this is a completely different RA instance then it ill be a new instance of the factory. This means that if there is a 2 branch xa transaction using the incoming and outgoing connections then the tm will use 2 phase commit, however it is possible, altho we hadnt changed it yet, that the same RA should return the same connection factory used for both which will allow the tm to optimize and use a 1 phase commit giving a marked improvement in performance.

     

    Ah yes, so assuming the TM can do a one phase commit optimization, it sounds like it only makes sense to do that with 1 inbound and 1 outbound, never multiple outbounds. Or am I missing something?

  • 72. Resource Adapter integration on AS7
    Jason Greene Master

    Andy Taylor wrote:

     

    btw, with regard too this bit of your config

     

       <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>

     

    thats exactly how i had envisioned that to be when rolled into the main messaging module, so at least we are on the same page with something

     

    Great. Yeah I realized you guys were right about about them being two different to compose.

  • 73. Resource Adapter integration on AS7
    Andy Taylor Master
    Yeah that could be done just marking one of them as also handling inbound. As to forced sharing of outgoing & incoming it sounds like your next comment that that is what you want?

    Yeah, but we should always have one by default, any deployed MDB's need a default inbound, this would be jms-ra.rar in AS5 so we either need to always have an inbound or just to always create one and let the user override it. also, i'm not sure how this would look in the config as there are things configured on the inbound that arent connection factory specific, such as destination type, how we look up the destination, retry attempts for connectig ets etc

     

    Ah yes, so assuming the TM can do a one phase commit optimization, it sounds like it only makes sense to do that with 1 inbound and 1 outbound, never multiple outbounds. Or am I missing something?

    yes, thats fine, allowing the user to pair them, you may have the default where bothe are invm but you may also need  a pait where both are remote which is probably more important as there is a bigger gain when the hq server is remote.

  • 74. Resource Adapter integration on AS7
    Leos Bitto Novice

    Andy Taylor wrote:

     

    We have done a lot of work with XA recently and had some optimisations that we were looking to do around this. basically a managed connection factory uses the Resource Adapter to create its connection factory, if this is a completely different RA instance then it ill be a new instance of the factory. This means that if there is a 2 branch xa transaction using the incoming and outgoing connections then the tm will use 2 phase commit, however it is possible, altho we hadnt changed it yet, that the same RA should return the same connection factory used for both which will allow the tm to optimize and use a 1 phase commit giving a marked improvement in performance.

     

    When XAResource#isSameRM(XAResource) returns true, the TM is be able to call XAResource#start(Xid, XAResource.TMJOIN) which gives the possibility to still use a 1 phase commit even with multiple XAResources (when all of them share the same HornetQ server transaction).