I'm adding new entries to my spec, then pushing it to the server. Twice now I've gotten back a list of invalid topic title / ID errors. I haven't modified the existing topics in the spec or in the repository, so the only thing I can think of is that the server is writing the wrong topic IDs into my spec when it processes it and hands it back. Permissive mode pushing is not useful as a workaround for this issue, as this aligns the topic title to the topic ID, but the wrong topic ID is being put next to the valid topic title that I specified. Here's an example. Spec ID is 7069. After pushing the spec, then adding a new chapter and pushing again, I get this error: ERROR: Line 70: Invalid Topic! Existing topic title doesn't match. -> Specified: Last Value Queues [8229] -> Topic 8229: Override the Default Group Name ERROR: Line 80: Invalid Topic! Existing topic title doesn't match. -> Specified: Rejected and Orphaned Messages [8035] -> Topic 8035: Queue Deletion Checks ERROR: Line 84: Invalid Topic! Existing topic title doesn't match. -> Specified: Queue Threshold Alerts [8180] -> Topic 8180: Queue Flow Control Properties ERROR: Line 98: Invalid Topic! Existing topic title doesn't match. -> Specified: Specify Queue Flow Thresholds with qpid-config [6974] -> Topic 6974: Durable Queues ERROR: Line 65: Invalid Topic! Existing topic title doesn't match. -> Specified: Message Queue [8227] -> Topic 8227: Message Group Example Use Cases ERROR: The Content Specification is not valid. cspclient-0.23.2-1.noarch OS: Fedora release 15 (Lovelock) JAVA: java version "1.7.0_01" Java(TM) SE Runtime Environment (build 1.7.0_01-b08) Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Yeah, it's definitely happening on the server. It is writing the post-processed spec with the wrong topic ID for some topics. There is a pattern to it. It writes the same topic ID for two topics (one correctly, one incorrectly). The incorrect one is written first, then the second correct one appears around 7-10 topics later. Take a look at this, from Spec 7069: Last Value Queues [8229] Declaring a Last Value Queue [8116] Section: Message Groups Message Groups [8226] Message Group Example Use Cases [8227] Message Group Consumer Requirements [8228] Configure a Queue for Message Groups using qpid-config [8231] Default Group [8230] Override the Default Group Name [8229] Notice the duplicated topic ID 8229. The second instance is correct, the first one is wrong and produces the error. The next topic in the spec is written as 8035, but it's the wrong topic ID. Notice that it appears later with the correct title. Override the Default Group Name [8229] Section: Alternate Exchanges Rejected and Orphaned Messages [8035] Alternate Exchanges [8056] Section: Queue Sizing Controlling Queue Size [8170] [R:T4] Queue Threshold Alerts [8180] Queue Threshold Alert Configuration [8156] Section: Deleting Queues Automatically Deleted Queues [8040] Queue Deletion Checks [8035] The next error is interleaved. Notice the topic 8180 between the two instances of 8035 above. It appears again shortly after the second (correct) 8035 instance: Queue Deletion Checks [8035] Section: Producer Flow Control [T4] Flow Control [8175] Queue Flow State [8182] Queue Flow Control Properties [8180] Again, the second instance is correct - the first instance of the Topic ID has been incorrectly written.
For the printing the line the error occurred on perhaps the debug information could be fine tuned so level 1 would just display the lines (before or after the error). Then actually make more debug output for different levels.
Ignore the previous comment it was meant for Bug #815588
This could be a difficult bug to diagnose the problem of. I have seen it a long time ago but only once and it's never happened again. I suspect it is an issue with a regex expression in the post content spec generation since the topics appear to be created fine but just the wrong ids have been injected.
I need more information as I've gone through every revision stored on the server and can't see any errors. What I need is: - What new items were you adding? Was it the new topic that got corrupted, was it another new topic or an existing one that got corrupt. - The revision that the issue occurred at. What would be handy to have: - The pre processed spec that you used to push to skynet. (Though if you've got the revision it should be stored on the server) In future if your going to post a ID and continue to edit the file (which I suspect is why I couldn't find the revision) then can u post the revision number as well.
Another item that would be handy to have is if you added any new tags. Another possible cause is that the wrong CSP Property value is being set and as such the wrong id is being set for those topics (this only happens for new, cloned or updated existing topics).
Since there's been no response to anything I asked for, I'm closing this bug. If it happens again feel free to open another bug with adequate details.
Created attachment 598772 [details] Post-processed spec with duplicated topic IDs
Created attachment 598773 [details] Pre-processed spec that I pushed
Got this behavior again. Attached post-processed spec and pre-processed spec from the push. It was this push: INFO: Revisions for Content Specification ID: 8025 -> ID: 161816 on Mon, Jul 16, 2012 at 01:02:20 AM -> ID: 161812 on Mon, Jul 16, 2012 at 01:00:44 AM
The post content spec contains local changes Revision 161816 though contains the proper post processed content spec.
For anyone else who gets this, here's the workaround to fix it: Do: csprocessor revisions <specID> You'll get a list of revisions: INFO: Revisions for Content Specification ID: 8025 -> ID: 161816 on Mon, Jul 16, 2012 at 01:02:20 AM -> ID: 161812 on Mon, Jul 16, 2012 at 01:00:44 AM The top one is the content spec you have now (the post-processed one after your last push) less the local changes you are trying to push now. The second one is the pre-processed one from the last push. What's happened is that valid topic IDs from the second one were incorrectly rewritten by the CSP in the top one. So, get the last good spec: csprocessor pull --pre -r 161812 ^ Pull the pre-processed spec from your last push Then, install meld (visual diff tool) or similar (you could use diff on the command line, but it's not so visual and easy). Then open your local post-processed spec and your recently-pulled pre-processed spec in meld. Your local changes (the ones you just tried to push) will be highlighted, but meld is pretty smart and will match the other lines (as long as your local changes aren't a big restructure). Look for the mismatched lines, and in a text editor modify the incorrect topic IDs in your local spec to the correct values from the pre-processed revision that you pulled down.
I just got this again. Content spec 8025. pre-processed: 166669 post-processed: 166673 One thing I notice here is that fixed topic IDs have changed between pre- and post-. There is no way to tell if I pushed with -p, but under normal circumstances that shouldn't happen. The timestamp on the topic in Skynet seems wrong, because I was doing this around 7pm, not 4.23pm. This one is particularly worrying to me because I found it only after I built and noticed something wrong. At the moment I'm staging things to put bugs on ON_QA for a release. I can't be checking to make sure that the right topics are in there manually as well... help!
Something else that would help is to keep a backup of the last content spec that was pushed, perhaps in a hidden directory. You could do the n-latest pattern: Keep the last five specs that were pushed in a .cache directory or similar. Then doing comparisons and troubleshooting would be a lot easier. My manual workaround atm is to: 1. Copy the contentspec before pushing it 2. Push the spec 3. Open the returned post-contentspec and the copied pre-contentspec in a visual diff tool 4. Make sure that nothing changed that shouldn't have.
Closing this since it hasn't been reported again and how the spec is generated has changed since this bug. If it does happen again feel free to re-open the bug.