The problem here turned out to be inconsistency in when and where
names were turned into file system safe identifiers. I've fixed it
and also made the RecoveryListenerAdapter throw an exception when it
encounters a reference to a non-existent message. I plan to move the
test case to a better location.
I'll be interested to see if this helps with some of the other durable
subscriber problems I've seen mentioned such as on IRC yesterday.
thanks
david jencks
On Jan 1, 2009, at 4:41 AM, Rob Davies wrote:
Great! - thx David
On 1 Jan 2009, at 12:16, David Jencks wrote:
I found a fairly simple way to reproduce the problem, see https://issues.apache.org/activemq/browse/AMQ-2052
. Hopefully this will make it easier to track down and fix :-)
thanks
david jencks
On Dec 29, 2008, at 10:46 PM, Rob Davies wrote:
Understand your problem. These messages can be the symptom of a
bug - usually in in org.apache.activemq.broker.region.cursors (see
StoreDurableSubscriberCursor) - would certainly like to help iron
this out
cheers,
Rob
On 30 Dec 2008, at 00:31, David Jencks wrote:
On Dec 29, 2008, at 10:29 AM, Rob Davies wrote:
this could be a bug - could you produce a test case ?
At this point, the test case is "set up and run the jms tck on
geronimo and look in the geronimo log to see these messages". I
was kinda hoping for a pointer on where to look to narrow things
down a bit. I __think__ but am not sure that these have
something to do with durable subscribers.... which I'm having
other problems with. If these messages are expected or don't
indicate a problem I don't want to spend a lot of time on this
particular issue.
thanks
david jencks
On 29 Dec 2008, at 17:24, David Jencks wrote:
On Dec 29, 2008, at 1:15 AM, Rob Davies wrote:
which version are you using David ?
activemq trunk. I have a couple local modifications but I
don't think they cause this -- they are far from the kaha code.
thanks
david jencks
On 25 Dec 2008, at 20:12, David Jencks wrote:
I'm working on trying to get the tck to pass with activemq
trunk in geronimo. When I run a failing test twice the
server log shows stuff like this:
2008-12-25 11:37:08,567 ERROR [RecoveryListenerAdapter]
Message id ID:pb.local-56923-1230232035140-2:13:1:1:1 could
not be recovered from the data store - already dispatched
2008-12-25 11:37:08,574 ERROR [RecoveryListenerAdapter]
Message id ID:pb.local-56923-1230232035140-2:12:1:1:1 could
not be recovered from the data store - already dispatched
(lots and lots of times, each )
This seems to be from RecoveryListenerAdapter:
public boolean recoverMessageReference(MessageId ref) throws
Exception {
Message message = this.store.getMessage(ref);
if (message != null) {
return recoverMessage(message);
} else {
LOG.error("Message id " + ref + " could not be recovered
from the data store - already dispatched");
}
return false;
}
My guess is that the reference store has a reference to a
message that is no longer in the message store. Is this a
problem or an expected state? If its unexpected, does anyone
have any ideas on where to look to figure out how we got into
this state?
thanks
david jencks
