Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How to view the contents of the fileStore to debug Persistence and durable subscriptions

2 views
Skip to first unread message

Todd Flora

unread,
Aug 24, 2001, 5:31:55 PM8/24/01
to

All,

Is there a way to browse the contents of the file store. I can open it in an editor
but am having trouble making it out as it seems to be binary. In trying to debug
my durable subscriptions and persisted messages it would be helpful to be able
to see the contents of the store.

I am currently having problems with this aspect of the new WL6.1 JMS.

Here is my actual problem

1) I subscribe durably to a topic. (i.e. I set the clientID of the connection
and create a DurableSubscriber on a particular durableID for an administered
topic.

2) I then send messages to that topic. And as long as the subscriber is currently
listening he gets the messages. Even if he is not connected he will get the messages
no problem when he resubscribes.

3) The problem seems to come in if the appserver goes down. I am currently using
JDK1.31 but still the messages are not received by the durable subscriber the
next time he comes on line.

I am setting the expiration to 0 (forever) on the messages and the deliveryMode
to Persistent. All of this worked fine in wl5.1 so I believe my code is sound.

I need to verify that the messages are not deleted from the store when the appserver
goes down.

Any help would be appreciated.

Regards,

Todd

Zach

unread,
Aug 24, 2001, 5:15:13 PM8/24/01
to
There is currently no way to browse/view the store. There
is an outstanding enhancement request for this. When you
say the server goes down, you mean in a bad way? or just
shutdown.

You might try turning on tracing. I am not sure what you would
get out of it but it may be worth a try to help us debug the problem
add the following within the <Server> portion of your config.xml

<ServerDebug
DebugJMSStore="true"
DebugJMSBoot="true"
DebugJMSBackEnd="true"
/>

and let us know what you get. We will run a similar scenario
here.

_sjz.

"


Todd Flora

unread,
Aug 24, 2001, 6:20:31 PM8/24/01
to

Thanks Zach,

I was wondering if you would ever talk to me again. I am just shutting down the
server and restarting it.

I will try the debugging suggestion.

Cheers,

Todd

Todd Flora

unread,
Aug 24, 2001, 8:49:47 PM8/24/01
to

As you expected. The debugging messages are really not helpful to me in determining
the problem. Let me know if you want me to email them to you

Thx

Todd

Tom Barnes

unread,
Aug 24, 2001, 8:04:35 PM8/24/01
to Todd Flora
The following program gives a complete statistics dump, it may help:
http://developer.bea.com/docs/jmsfaq.jsp#_TOC1121

The FAQ has an entry on common persistence problems. Check
that your configuration is correct based on this.
http://developer.bea.com/docs/jmsfaq.jsp#_TOC118

Zach

unread,
Aug 27, 2001, 12:12:47 AM8/27/01
to
I wrote a small test program. It creates a durable subscriber,
sends a message to itself (the durable subscription) and then
exits without attempting to receive or to unsubscribe. I then
run the same program with different options, where it creates
the durable subscriber and simply receives the message (and
then unsubscribes). In between the first and second run I
shut down and reboot the server.

Works like a charm. I received the message sent to my
durable subscriber before the reboot. The only thing that
you describe that I didn't do is set the expiration time to
zero - will try that next.

Somes things you may want to check (even though I know you
already gave information on some of this). Look at the message
id that you get back when you send the message. If it starts
with a "P:" the message was stored persistently. If it starts with
a "N:" then the message was not stored. If the message id
starts with an "N", check the deliveryMode of the message
before and after it is sent. Check the deliveryMode of the
producer. Check to make sure the topic does not have a
deliveryMode override. Check to make sure the connection
factory doesn't have a default delivery mode of "Non-Perisistent".
Check to make sure the store actually exists. And when you
reboot, use the JMSStats program to verify that the durable
subscription exists and it contains the proper number of messages
before you start your program after the reboot. Use the
JMSStats program before you shutdown even to make sure the
messages haven't been completely consumed before shutdown.

If all of that checks out, then check your actual subcription code.
You must use the same clientId every time, the durable subscriber
name, the selector and the noLocal flag must be identical the
second time around. Don't be tempted into using the one without
the selector and noLocal if you used the other signature the first
time. You have to use the exact same method with the exact
same parameters or it replaces your subscription. Replacing
the subscriber means deleting the old durable subscriber and
creating a new one. This implies that all the messages in the
original durable subscriber are purged. If you see messages
with the JMSStats program on reboot, and then you resubscribe
but don't attempt to receive and all the messages go away (run
JMSStats again), then your subscriptions may not match.

When I check the expiration thing, you say you set the
expiration do you mean the timeToLive on the producer, or
do you really mean the expiration. I just want to be sure
there is no nasty side effect if you set the expiration on the
message.

_sjz.


"Todd Flora" <tfl...@doradosoftware.com> wrote in message
news:3b86e81b$1...@newsgroups.bea.com...

Zach

unread,
Aug 27, 2001, 12:18:21 AM8/27/01
to
I am here to help. It doesn't always work out that way but that is
definitely the idea.
_sjz.

"Todd Flora" <tfl...@doradosoftware.com> wrote in message

news:3b86...@newsgroups.bea.com...

Todd Flora

unread,
Aug 27, 2001, 3:07:12 PM8/27/01
to

Tom, Zach,

Unfortunately I can't get the JMSStats utility to work. When I attempt to run
it with I get the following dump from the client

Note: The password has been changed to asterisks for security reasons. The password
was our valid system user password.

Using url=t3://localhost:7001 user=system pass=********** bean=null
Exception in thread "main" javax.naming.CommunicationException. Root exception
is weblogic.rjvm.PeerGoneException: ; nested exception is:
java.io.EOFException
java.io.EOFException
at weblogic.rjvm.t3.T3JVMConnection.endOfStream(T3JVMConnection.java:599)
at weblogic.socket.JavaSocketMuxer.processSockets2(JavaSocketMuxer.java:303)
at weblogic.socket.JavaSocketMuxer.processSockets(JavaSocketMuxer.java:225)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

The server also has a huge dump as well.

java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local c
lass serialVersionUID=-8308522755600156056
at java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:29)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:66)
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:38)
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:175)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Exception creating
response stream ] - with nested exception:
[java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local
class serialVersionUID=-8308522755600156056]
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:184)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
<Aug 27, 2001 11:04:03 AM PDT> <Error> <NT Performance Pack> <failure in processSockets()
- GetData: 'weblogic.socket.GetData@3b71ac - fd: '2880', num
Bytes: '1069''
java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local c
lass serialVersionUID=-8308522755600156056
at java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:29)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:66)
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:38)
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:175)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Exception creating
response stream ] - with nested exception:
[java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local
class serialVersionUID=-8308522755600156056]
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:184)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
>
java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local c
lass serialVersionUID=-8308522755600156056
at java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:29)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:66)
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:38)
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:175)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Exception creating
response stream ] - with nested exception:
[java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local
class serialVersionUID=-8308522755600156056]
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:184)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
<Aug 27, 2001 11:04:03 AM PDT> <Error> <NT Performance Pack> <failure in processSockets()
- GetData: 'weblogic.socket.GetData@5be21d - fd: '2904', num
Bytes: '1069''
java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local c
lass serialVersionUID=-8308522755600156056
at java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.ClassTableEntry.readExternal(ClassTableEntry.java:29)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at weblogic.rjvm.InboundMsgAbbrev.readObject(InboundMsgAbbrev.java:66)
at weblogic.rjvm.InboundMsgAbbrev.read(InboundMsgAbbrev.java:38)
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:175)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Exception creating
response stream ] - with nested exception:
[java.io.InvalidClassException: javax.security.auth.Subject; Local class not compatible:
stream classdesc serialVersionUID=-6842430708383393570 local
class serialVersionUID=-8308522755600156056]
at weblogic.rjvm.MsgAbbrevJVMConnection.readMsgAbbrevs(MsgAbbrevJVMConnection.java:184)
at weblogic.rjvm.MsgAbbrevInputStream.readMessageContext(MsgAbbrevInputStream.java:154)
at weblogic.rjvm.ConnectionManager.dispatch(ConnectionManager.java:581)
at weblogic.rjvm.t3.T3JVMConnection.dispatch(T3JVMConnection.java:454)
at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:638)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:137)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

Any Help would be appreciated.

Regards,

Todd

Zach

unread,
Aug 27, 2001, 2:19:10 PM8/27/01
to
It looks like you are using different versions of the software on the
client and server. But even without JMSStats you should be able
to tell at least if the message id being returned starts with an N or P.

Feel free to post the JMS portion of your configuration, and or your
test program.

_sjz.


Todd Flora

unread,
Aug 27, 2001, 4:08:45 PM8/27/01
to

Zach,

I do have the default deliveryMode on the TopicConnectionFactory set to Non-Persistent
(but I thought this was acceptable). The topic params are EnableStore=default,
DeliveryModeOverride=No-Delivery, MessageID after received does contain a 'P:'

The persistent store does exist.

That's all I have so far. I am not sure how I could be using different versions
as my environment only points to the wl61 jar.

I will get back when I have more info.

Regards,

Todd

Zach

unread,
Aug 27, 2001, 3:30:07 PM8/27/01
to
So the next thing is, how are you creating the durable subscriber.
Is it the exact same code both times? Or is there some code that
does one thing to create the durable subscriber and then a different
thing when you expect the durable subscriber to already exist?

_sjz.

Todd Flora

unread,
Aug 27, 2001, 5:17:54 PM8/27/01
to

Zach,

NoLocal is hardcoded as false. The Selector is exactly the same. The clientID
set into the connection is the same as it is a combo of the machineName, UserID
and _c for client or _s for server. I am running all the tests on the same box
with the same user ID. The durableName is also the same.

Regards,

Todd

Todd Flora

unread,
Aug 27, 2001, 5:27:37 PM8/27/01
to

Zach,

One other thing you might try.

We are setting the clientID into the connection immediately after it is created
rather than using a TopicConnectionFactory that defaults the clientID.

Regards,

Todd

Todd Flora

unread,
Aug 27, 2001, 6:16:42 PM8/27/01
to

Zach,

Here is my output

java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -s
Sent TextMessage[ID:N<454630.998946646321.0>, TestMessage]

java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -r
-d
Received null

I receive nothing when performing the same steps.

Regards,

Todd

Todd Flora

unread,
Aug 27, 2001, 6:18:25 PM8/27/01
to

Duh, This is a stupid Todd Error

I forgot to set the default to persistent because apparently you are not setting
it in your test. give me a minute to try again.

Todd

Zach

unread,
Aug 27, 2001, 5:25:49 PM8/27/01
to
The default is PERSISTENT. The N coming back
would indicate some kind of override.

_sjz.

"Todd Flora" <tfl...@doradosoftware.com> wrote in message

news:3b8a...@newsgroups.bea.com...

Todd Flora

unread,
Aug 27, 2001, 6:39:01 PM8/27/01
to

Our DefaultTopicConnectionFactory was set to Non-Persistent. The topic I created
for this test had a deliveryModeOverfide="No-Delivery"

Anyway I did as many tests as I could think of.

1) DefaultTopicConnectionFactory defaultDeliveryMode="Non-Persistent" TopicPublisher.setDeliveryMode="Persistent"
and Message.setJMSDeliveryMode = "Persistent"

Output


java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -s

Sent TextMessage[ID:P<973480.998947130247.0>, TestMessage]


ava TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -r

Received null

2) Change the Topic's overrideDeliveryMode="Persistent"


java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -s

Sent TextMessage[ID:P<716798.998947431620.0>, TestMessage]


java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -r

Received null

3) Change the DefaultTopicConnectionFactory defaultDeliveryMode="Persistent"


java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -s

Sent TextMessage[ID:P<457195.998947604428.0>, TestMessage]


java TestDurable -f oware.jms.topicconnection.factory -t javax.jms.TestTopic -r

Received null

As you can see nothing I do seems to result in the appropriate response and my
ID is Now P: Persistent.

Regards,

Todd

Tom Barnes

unread,
Aug 27, 2001, 5:57:16 PM8/27/01
to Todd Flora
To not get a "receive null" below, you need to run
the durable subscriber before you run the sender, or the durable
subscription must already exist.

The JMSStats program will
dump info on durable subscribers if you are using 6.1. BTW I don't know why
JMSStats is not working for you, seems like a CLASSPATH
problem or the client and server are using incompatible weblogic.jar files...

Are you setting an expiration time on the message? This can cause
the message to "disappear" on you.

Is there an Override on the Topic configuration set to non-persistent?
Don't want that. How about the Override on the Topic's Template (which
the Topic may inherit).

Are you sure your are calling "createDurableSubscriber" rather than "createSubscriber" to
create the subscriber? Is the topic a permanent topic, or
is it a "temporary" topic that is created dynamically? Temporary topics
don't exist past the life of the connection that creates them.

Todd Flora

unread,
Aug 27, 2001, 7:03:45 PM8/27/01
to

Hey Tom,

The Durable subscriber does already exist as you can see from the first -s send.


I then take down the appserver and bring it back up. And issue the -r. I am just
running the test App just as Zach said to.

Regards,

Todd

Todd Flora

unread,
Aug 27, 2001, 8:39:56 PM8/27/01
to

Zach,

I think I have gotten to the bottom of this. We seed the config.xml file each
time the appserver is started. We do this by overwriting the current config.xml
with an init_config.xml. The reason we do this is so that we are assured at startup
that we always start the appserver with a correct set of options. If the user
changes these options this assures us that even if he breaks the appserver it
will work the next time it comes up.

As per a previous post we create all our JMS Topics dynamically. The next time
the server is started the config.xml is reseeded and any jms topics that were
dynamically created in the last session are obviously gone.

At first I thought this was the problem so I added my test topic to the init_config.xml
(the file that seeds config.xml). This still did not solve the problem. So I next
turned off the seeding of the config.xml file and it worked. Therefore I believe
that somehow the appserver is comparing some internal copy of the config.xml with
the one we maintain. When it sees that it is differernt (dateTime, FileHandle
whatever) it then purges the jmsStore. Is this a problem that we can resolve or
just a functions as designed issue? If it has to be that way is there a way for
me to work around this?

Even if this problem were resolved I would assume that if a topic were created
in appserverSession1 and then the config.xml file were reseeded in appserverSession2
that a scavenger would remove messages from the store for topics that now did
not exist yet.

Therefore I will have to write a mechanism that tracks the creation of topics
and seeds the config.xml file with these. This was so much easier when we used
a DB.

Regards,

Todd

Todd Flora

unread,
Aug 27, 2001, 9:11:17 PM8/27/01
to

Tom,

See comments inline.

Tom Barnes <dev....@not.my.address.com> wrote:
>To not get a "receive null" below, you need to run
>the durable subscriber before you run the sender, or the durable
>subscription must already exist.
>

It already exists from the first call to the testDurable app with a send.

>The JMSStats program will
>dump info on durable subscribers if you are using 6.1. BTW I don't know
>why
>JMSStats is not working for you, seems like a CLASSPATH
>problem or the client and server are using incompatible weblogic.jar
>files...

I will look at this and try and get it working.

>
>Are you setting an expiration time on the message? This can cause
>the message to "disappear" on you.

Expiration is set to 0 (forever)

>
>Is there an Override on the Topic configuration set to non-persistent?

No

>Don't want that. How about the Override on the Topic's Template (which
>the Topic may inherit).

No Template assoc with topic.

>
>Are you sure your are calling "createDurableSubscriber" rather than "createSubscriber"
>to
>create the subscriber?

Yes. This is an app that was working with wl51

>Is the topic a permanent topic, or
>is it a "temporary" topic that is created dynamically? Temporary topics
>don't exist past the life of the connection that creates them.

Permanent!


Regards,

Todd

Zach

unread,
Aug 27, 2001, 9:22:46 PM8/27/01
to
On startup, we receive our configuration from the admin server. Then we
open the store and read all of the messages. Any messages that do not
match a configured destination are purged. The equivalence test for
whether a message matches a given destination is the "Name" of the
destination (not the JNDIName). You say you create the topics dynamically?
At run-time? After JMS and the server has booted? If so that pretty much
explains it. If the config file contains no topics, then no message will
match the topics, and we purge all the messages. The same is true for the
durable subscribers that have no topic to belong to.

Note, in 6.x, if you were using a database it would behave the same way.
Could yo
_sjz.


Tom Barnes

unread,
Aug 28, 2001, 10:16:03 AM8/28/01
to Todd Flora
> >Is the topic a permanent topic, or
> >is it a "temporary" topic that is created dynamically? Temporary topics
> >don't exist past the life of the connection that creates them.
>
> Permanent!

Temporary! (Couldn't resist)

Gah! I'm glad you figured this out on your own.

It turns out you are removing all configured topics from the config.xml
each time you reboot, according to your post on a related thread.
In effect, your destinations are temporary after all, they only last
while the server runs - as removing topics from the config.xml prior
to reboot implies their deletion.

There is a log message
that gets printed that announces the number of messages found
in deleted destinations:
JMSServer "{0}", deleting {1} messages(s) with no matching destination.
(We should have asked you to check your log.)

And yes, before you start making suggestions, it would be
nice to move queue/topic configuration out of the config.xml for
various reasons - but there are also advantages to leaving
it in there. If you want to discuss this, take it up with Zach. I'm
supposed to be retiring w.r.t. JMS.

Todd Flora

unread,
Aug 28, 2001, 12:44:26 PM8/28/01
to

Tom,

You are just a laugh an hour. :-)

The thing that bothers me about this is that actually the contents of the config.xml
does not change. Yes for dynamic topics it does but I have actually set the topics
I am testing with up in the init_config.xml file and therefore the contents of
the config.xml on subsequent startups of the appserver is exactly the same.

I have to assume that the server is keying on the create date of the file or something
because as just stated the topics are there from startup to startup.

Regards,

Todd

Todd Flora

unread,
Aug 28, 2001, 12:56:18 PM8/28/01
to

Zach,

Maybe I wasn't clear so I will try again.

Yes I realize that topics that aren't there when the server restarts would have
their durable subscribers and messages purged.

What I was trying to tell you though is that even a topic that is static (one
that always exists in the config.xml file) is being purged. What is causing this
is that we are rewriting the config.xml file from an Init_config.xml file. The
create date/time is changing but the contents of the file is exactly the same
from startup to startup. Therefore the topics are there when we restart yet the
messages still get purged.

Call me at 916-673-1055 if you still don't understand what I am trying to say
as this is kind of hard to explain. Suffice it to say that the config.xml file
contents is exactly the same from startup to startup including the jms section
with the topics. Just by copying an exact duplicate of the file between restarts
causes the messages to be purged.

Regards,

Todd

Todd Flora

unread,
Aug 28, 2001, 1:33:58 PM8/28/01
to

BTW,

I did get to the bottom of why JMSStats was not working for me.

Apparently weblogic has defined their own javax.security.auth.Subject. We are
using the jaas.jar from javasoft which provides this class and your jar also contains
this class. The server is using your version my client is using javasoft's version.
Your class is not the same as the published version from javasoft and hence the
"Local class not compatible" error.

Is this a bad thing that wl has done by publishing a java defined class in their
library. It seems we had problems with this as well in wl51 because the javax
libraries were provided in the weblogicaux.jar. When we upgraded to jdk1.3 we
were trying to access features of the new swing components only to find that the
wl51 jar was first in the path and causing the old components to be surfaced.

Regards,

Todd

Zach

unread,
Aug 28, 2001, 1:08:54 PM8/28/01
to
I would post this in the security newsgroup.
_sjz.

"Todd Flora" <tfl...@doradosoftware.com> wrote in message

news:3b8bc7f6$1...@newsgroups.bea.com...

Tom Barnes

unread,
Aug 28, 2001, 1:09:44 PM8/28/01
to Todd Flora
> I have to assume that the server is keying on the create date of the file or something
> because as just stated the topics are there from startup to startup.
>

Absolutely no such thing. None. Something else is wrong. See other post. Lets
stop this thread, and please respond to the Zach's thread. There are a number
of things there to check. Something basic is going wrong here, and likely not to do with
BEA code.

Tom Barnes

unread,
Aug 28, 2001, 1:07:03 PM8/28/01
to Todd Flora
The jaas.jar you are using contains either an older or newer version of this class. BEA
does not write its own javax interfaces.

It is not possible
for an app server to support multiple versions of a javax class, unless the
serialVersionUID is hard-coded (by javasoft) to facilitate versioning.

Glad you found the error.

Tom Barnes

unread,
Aug 28, 2001, 1:24:15 PM8/28/01
to Todd Flora
If config.xml is the same, then no messages will get deleted. Period. There
is no check for date/time/checksum on the config.xml, or anything remotely similar.

Again, you can see if messages are getting deleted on boot by looking for the log
message I wrote you
in the other thread in this post. Log message: JMSServer "{0}", deleting {1}
messages(s) with no matching destination. There is also a JMSServer "{0}",
expiring {1} messages(s).

Again, now that you know how to use the stats program, does it report durable
subscribers before AND
after the reboot? Note that durable subscription stats only work for 6.1...

Zach

unread,
Aug 28, 2001, 1:35:21 PM8/28/01
to
And I just tried this myself. I edited the config.xml file (added a
comment)
and then rebooted. I get all the messages. What topics are listed in your
config.xml.booted file? And like Tom asked is there anything in the log
saying that you messages were deleted? I personally would like to see
the contents of the config.xml file, the seeded file, the .booted file and
so forth.

On my machine everything just works (and it all works on the first try,
no dorking around with configurations or anything). And I seem to
recall you said you got it to work if you didn't do the reseeding thing.
Now I have "reseeded" my file and it just works.

_sjz.

0 new messages