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
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.
"
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
Thx
Todd
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
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...
"Todd Flora" <tfl...@doradosoftware.com> wrote in message
news:3b86...@newsgroups.bea.com...
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
Feel free to post the JMS portion of your configuration, and or your
test program.
_sjz.
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
_sjz.
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
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
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
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
_sjz.
"Todd Flora" <tfl...@doradosoftware.com> wrote in message
news:3b8a...@newsgroups.bea.com...
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
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.
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
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
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
Note, in 6.x, if you were using a database it would behave the same way.
Could yo
_sjz.
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.
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
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
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
"Todd Flora" <tfl...@doradosoftware.com> wrote in message
news:3b8bc7f6$1...@newsgroups.bea.com...
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.
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.
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...
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.