Initial durable subscription setup

[npujol]

Hi,

I was wondering if it was wrong to insert a row manually in theJMS_SUBSCRIPTIONS at table creation time in order to register a durable subscription? In my mysql-jdbc-state-service.xml:

<attribute name="SqlProperties">
 ....
 POPULATE.TABLES.01 = INSERT INTO JMS_SUBSCRIPTIONS (CLIENTID, SUBNAME, TOPIC, SELECTOR) VALUES ("_ownsubscriber", "_emailSender0","NotificationDurableTopic","subscribers like '%email%'")
 ....
</attribute>

I think it is not - I am basically mimicing a managed topic just like it would be done in a jbossmq-state.xml with something like this:

<DurableSubscription>
 <ClientID>_ownsubscriber</ClientID>
 <Name>_emailSender0</Name>
 <TopicName>NotificationDurableTopic</TopicName>
 <Selector>subscribers like '%email%'</Selector>
</DurableSubscription>

It is my understanding that both ways of doing it basically relieve the JMS client code from having to specify the client id and subscription name on their durable subscriptions. In my environment it does seem to work though the jbossmq's client subscriber code

topicSession.createDurableSubscriber(topic,"_emailSend0");

insists in adding a new row to JMS_SUBSCRIPTIONS and my JMS_SUBSCRIPTIONS table ends up looking like this:

+----------------+---------------+-----------------------------+----------------------------+
| CLIENTID | SUBNAME | TOPIC | SELECTOR |
+----------------+---------------+-----------------------------+----------------------------+
| _ownsubscriber | _emailSender0 | NotificationDurableTopic | subscribers like '%email%' |
| ID:2 | _emailSender0 | NotificationDurableTopic | NULL |
+----------------+---------------+-----------------------------+----------------------------+

It looks like I am missing a piece in my setup : I must associate the user with the connection as is done in jbossmq-state.xml by matching the User node with the durable subscription node. Does anybody know if it is even possible to create this association with a jboss-jdbc-state-service.xml DB setup? Thanks in advance

[npujol]

Ok I am one step further as I found a way to make the association between the user and his connection thought I still have a problem with the message selector being nulled out. The trick is simply to make the association in the JMS_USERS tables by adding an entry in the mysql-jdbc-state-service.xml. So now that file looks like this:

<attribute name="SqlProperties">
....
 POPULATE.TABLES.01 = INSERT INTO JMS_USERS (USERID, PASSWD, CLIENTID) VALUES ('ds_user', 'changeit', '_ownsubscriber')

 POPULATE.TABLES.02 = INSERT INTO JMS_SUBSCRIPTIONS (CLIENTID, SUBNAME, TOPIC, SELECTOR) VALUES ("_ownsubscriber", "_emailSender0","IDMNotificationDurableTopic","subscribers like '%email%'")
....
</attribute>

Note that for some reason the SELECTOR column does get cleared upon a call to

topicSession.createDurableSubscriber(topic,"_emailSend0");

Does anybody know why? I don't believe this is correct! thoughts?

[npujol]

Ok I am one step further as I found a way to make the association between the user and his connection thought I still have a problem with the message selector being nulled out. The trick is simply to make the association in the JMS_USERS tables by adding an entry in the mysql-jdbc-state-service.xml. So now that file looks like this:

<attribute name="SqlProperties">
....
 POPULATE.TABLES.01 = INSERT INTO JMS_USERS (USERID, PASSWD, CLIENTID) VALUES ('ds_user', 'changeit', '_ownsubscriber')

 POPULATE.TABLES.02 = INSERT INTO JMS_SUBSCRIPTIONS (CLIENTID, SUBNAME, TOPIC, SELECTOR) VALUES ("_ownsubscriber", "_emailSender0","IDMNotificationDurableTopic","subscribers like '%email%'")
....
</attribute>

Note that for some reason the SELECTOR column does get cleared upon a call to

topicSession.createDurableSubscriber(topic,"_emailSend0");

Does anybody know why? I don't believe this is correct! thoughts?

[npujol]

According to the JMS 1.1 spec in section 6.3 towards the end:

All JMS providers must be able to run JMS applications that dynamically create
and delete durable subscriptions. Some JMS providers may, in addition,
provide facilities to administratively configure durable subscriptions. If a
durable subscription has been administratively configured, it is valid for it to
silently override the subscription specified by the client.

Shouldn't JbossMQ make sure that a call to topicSession.createDurableSubscriber(topic,subname) does not override what may have been setup in JMS_USERS? Or does this problem arise because the JMS_USERS approach to adding a subscription is trully not an "administered" way of dealing with a topic?