[JBoss Messaging] - Re: Different Message id for each listener
by timfox
"assaf49" wrote : Scenario:
| A JMS Connection is used to create 10 JMS listeners on Topic MyTopic.
|
By "listener" I'm assuming you mean non durable subscription (?)
And I'm assuming you're not using MDBs since you haven't mentioned them.
anonymous wrote :
| Each Listener has a different selector (some have OVERLAPPING selector properties).
|
| 1) Producer sends Message A.
|
| 2) Some Connection failure occurs on the Listeners side
|
Does message A get received before failure?
I will assume yes since you haven't specified.
What do you mean "connection failure"? Does the client process crash? I will assume yes here too.
anonymous wrote :
| 3) Producer sends Message B
|
|
Does the producer send message B before or after the non durable subscription is recreated?
Please note that non durable subscriptions *do not survive* failure so any messages sent when they are non created (i.e. after the crash but before the recreation) will be *lost*.
This is perfectly normal behaviour, see JMS spec for more details about differences between non durable and durable subscriptions.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116465#4116465
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116465
18 years, 3 months
[Beginners Corner] - Re: Problem starting service persistence.units (ClassCastEx
by mjhammel
Excellent catch, jaikiran! I had several "version" fields in various tables, one of which (and only one) was defined as a varchar. Checking the generated hbm I found that this was being defined as a Hibernate version element, which it didn't need to be. Changing that one field to a name different than "version" cleared the problem. I've now changed all "version" fields to be prefixed with a table identifier to avoid this issue in the future.
Many thanks. It sure is nice to start the new year with a completely unclear problem clarified. :-)
I have one more minor issue that cropped up on deployment after fixing this problem. I get a number of messages like this:
10:14:41,326 ERROR [SchemaExport] Unsuccessful: create table crunch.tool (guid varchar(50) not null, state integer, displayName text, Application varchar(50), lastUpdate datetime, wrapperGuid varchar(50), helpGuid varchar(50), toolVersion text, interpreter varchar(50), addDate datetime, lastUse datetime, toolOwner varchar(50), fileGuid varchar(50), toolTypeGuid varchar(50), toolValidator varchar(50), primary key (guid))
| 10:14:41,326 ERROR [SchemaExport] Table 'tool' already exists
I believe this is because my persistence.xml includes this line:
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
And because I've already loaded the db prior to deployment (as part of the build process in order to do the Hibernate reverse engineering). Removing this line from persistence.xml causes other problems. These messages are only informative as far as I can tell, but it would be nice to eliminate them to make a clean deployment. Do you know how I might be able to do this?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116462#4116462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116462
18 years, 3 months