Hello Damien, First of all, good to hear that you found the problem!
ACE stores the full URL of artifacts on purpose. A relative URL would not work, because ACE cannot assume that the “server” and “OBR” part are running on the same machine. In fact, those URLs can point to any artifact anywhere. If you want to keep moving the OBR (or the whole ACE server) around, you should probably consider some kind of load balancing solution to ensure it is always reachable through a fixed name. Another solution you could consider is to create your own URL handler, so the handler can resolve the URLs to the real location. That is a bit more work to setup though. Greetings, Marcel On 06 Mar 2014, at 14:11 , Damien Martin-Guillerez <[email protected]> wrote: > Hello, > > I finally found the problem. It has nothing to do with the disk quota but it > is related to the solution. I moved the Apache ACE instance to another > machine. Because of some issues with internal DNS, I have used static ip in > Apache ACE configuration. > Anyway the problem is that in the ACE server repository, it is storing the > full URL of artefacts instead of one relative to the OBR repository. So I > just replaced the occurrence of the old ip with the new ip in the XML files > and it worked. > > I believe the stored URL should be relative, not absolute. Should I post a > feature request on JIRA? > > — Damien > > On 06 Mar 2014, at 11:37, Marcel Offermans <[email protected]> > wrote: > >> On 06 Mar 2014, at 9:50 am, Damien Martin-Guillerez >> <[email protected]> wrote: >> >>> I suppose that the org.apache.ace.repository.impl bundle is the one >>> containing the potentially broken data. I went in it and there is two >>> folders: repos and tmp. Deleting tmp made no change, deleting repos cleared >>> all the links data that I would like to keep (If I cannot do it, I will >>> simply drop everything using the REST API). Restoring the repos folder >>> recovers all the informations I need. >> >> Yes, that was indeed the bundle I meant. >> >>> The data in the repository is non understandable: >> >> It's not really meant to be read by humans, but with a bit of explanation >> it's not too bad. >> >> There are different repositories that ACE uses, that's why you see the >> factory pattern and generated "unique names" here. >> >> The numbered files are versions, so in general, search for the highest one >> to get to the latest data. >> >>> $ ls -R repos/ >>> repos/: >>> org.apache.ace.server.repository.factory.07b73c8e-821f-4a35-bcff-634e4c6a6130 >>> org.apache.ace.server.repository.factory.288e53af-700c-4167-843e-31602e6f9e1d >>> org.apache.ace.server.repository.factory.6c7e85b1-f0b3-4a56-9e50-fea310d2be6f >>> org.apache.ace.server.repository.factory.c74d457c-6595-4a55-9ab3-f2b3749b1558 >>> org.apache.ace.server.repository.factory.ce71c886-9d19-439a-9b26-8b8cfde9d6da >>> org.apache.ace.server.repository.factory.fdc95335-d67c-4992-b667-38809696d153 >>> >>> repos/org.apache.ace.server.repository.factory.07b73c8e-821f-4a35-bcff-634e4c6a6130: >>> 1 >>> >>> repos/org.apache.ace.server.repository.factory.288e53af-700c-4167-843e-31602e6f9e1d: >>> 1 109 119 129 139 149 159 169 179 189 199 208 218 228 238 >>> 248 258 268 278 31 41 51 61 71 81 91 >>> 10 11 12 13 14 15 16 17 18 19 2 209 219 229 239 >>> 249 259 269 279 32 42 52 62 72 82 92 >>> 100 110 120 130 140 150 160 170 180 190 20 21 22 23 24 >>> 25 26 27 28 33 43 53 63 73 83 93 >>> 101 111 121 131 141 151 161 171 181 191 200 210 220 230 240 >>> 250 260 270 280 34 44 54 64 74 84 94 >>> 102 112 122 132 142 152 162 172 182 192 201 211 221 231 241 >>> 251 261 271 281 35 45 55 65 75 85 95 >>> 103 113 123 133 143 153 163 173 183 193 202 212 222 232 242 >>> 252 262 272 282 36 46 56 66 76 86 96 >>> 104 114 124 134 144 154 164 174 184 194 203 213 223 233 243 >>> 253 263 273 283 37 47 57 67 77 87 97 >>> 105 115 125 135 145 155 165 175 185 195 204 214 224 234 244 >>> 254 264 274 284 38 48 58 68 78 88 98 >>> 106 116 126 136 146 156 166 176 186 196 205 215 225 235 245 >>> 255 265 275 29 39 49 59 69 79 89 99 >>> 107 117 127 137 147 157 167 177 187 197 206 216 226 236 246 >>> 256 266 276 3 4 5 6 7 8 9 >>> 108 118 128 138 148 158 168 178 188 198 207 217 227 237 247 >>> 257 267 277 30 40 50 60 70 80 90 >>> >>> repos/org.apache.ace.server.repository.factory.6c7e85b1-f0b3-4a56-9e50-fea310d2be6f: >>> 1 109 119 129 139 149 159 169 179 189 199 208 218 228 238 >>> 248 258 268 32 42 52 62 72 82 92 >>> 10 11 12 13 14 15 16 17 18 19 2 209 219 229 239 >>> 249 259 269 33 43 53 63 73 83 93 >>> 100 110 120 130 140 150 160 170 180 190 20 21 22 23 24 >>> 25 26 27 34 44 54 64 74 84 94 >>> 101 111 121 131 141 151 161 171 181 191 200 210 220 230 240 >>> 250 260 270 35 45 55 65 75 85 95 >>> 102 112 122 132 142 152 162 172 182 192 201 211 221 231 241 >>> 251 261 271 36 46 56 66 76 86 96 >>> 103 113 123 133 143 153 163 173 183 193 202 212 222 232 242 >>> 252 262 272 37 47 57 67 77 87 97 >>> 104 114 124 134 144 154 164 174 184 194 203 213 223 233 243 >>> 253 263 28 38 48 58 68 78 88 98 >>> 105 115 125 135 145 155 165 175 185 195 204 214 224 234 244 >>> 254 264 29 39 49 59 69 79 89 99 >>> 106 116 126 136 146 156 166 176 186 196 205 215 225 235 245 >>> 255 265 3 4 5 6 7 8 9 >>> 107 117 127 137 147 157 167 177 187 197 206 216 226 236 246 >>> 256 266 30 40 50 60 70 80 90 >>> 108 118 128 138 148 158 168 178 188 198 207 217 227 237 247 >>> 257 267 31 41 51 61 71 81 91 >>> >>> repos/org.apache.ace.server.repository.factory.c74d457c-6595-4a55-9ab3-f2b3749b1558: >>> 1 10 11 12 13 14 15 16 17 18 19 2 20 21 22 3 4 5 6 7 8 >>> 9 >>> >>> repos/org.apache.ace.server.repository.factory.ce71c886-9d19-439a-9b26-8b8cfde9d6da: >>> >>> repos/org.apache.ace.server.repository.factory.fdc95335-d67c-4992-b667-38809696d153: >>> >>> The first file is an xml file the others file are binary files (non-zip >>> files). >> >> They are not "zip" files but "gzip" files (you might need to add an >> extension for your tools to pick them up correctly). >> >> Greetings, Marcel >> >
