Routing internal snapshots
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Routing internal snapshots
by mihobson
::
Rate this Message:
Hi there,
I've set up a route to match internal artifacts that only checks our internally hosted repositories. The problem is that Maven still takes about one second per snapshot when checking for updates using -U. Is there anything I'm missing? I tried setting the log level to debug but I couldn't see any routing messages that stated which repositories where being checked. Thanks, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Routing internal snapshots
by mihobson
::
Rate this Message:
2009/8/20 Mark Hobson <markhobson@...>:
> Hi there, > > I've set up a route to match internal artifacts that only checks our > internally hosted repositories. The problem is that Maven still takes > about one second per snapshot when checking for updates using -U. Is > there anything I'm missing? I tried setting the log level to debug > but I couldn't see any routing messages that stated which repositories > where being checked. Any tips here? I saw from the similar thread that 1.4 will help diagnose these problems. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Brian Fox
::
Rate this Message:
There's no obvious reason why this would be slow. You could perhaps
adjust the cache expiration for your repositories. Does this happen everytime you do -U or just the first time after a while? On Mon, Aug 24, 2009 at 7:30 AM, Mark Hobson<markhobson@...> wrote: > 2009/8/20 Mark Hobson <markhobson@...>: >> Hi there, >> >> I've set up a route to match internal artifacts that only checks our >> internally hosted repositories. The problem is that Maven still takes >> about one second per snapshot when checking for updates using -U. Is >> there anything I'm missing? I tried setting the log level to debug >> but I couldn't see any routing messages that stated which repositories >> where being checked. > > Any tips here? I saw from the similar thread that 1.4 will help > diagnose these problems. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: nexus-user-unsubscribe@... > For additional commands, e-mail: nexus-user-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
Hmm yes, sorry, I forgot that I had to adjust the 'not found cache
TTL' to one minute for our internal snapshot and release repos to workaround this issue: http://www.nabble.com/Re%3A-Item-not-found-for-UID...message-for-SNAPSHOT-artifacts-on--Solaris-td23273378ef34835.html It does happen every time I do a -U. So is the best solution to configure Maven to deploy directly to Nexus, allowing the negative cache to be upped? I tried to check the Nexus documentation but it appears to have moved out from "Maven: The Definitive Guide". Any idea where to? Cheers, Mark 2009/8/24 Brian Fox <brianf@...>: > There's no obvious reason why this would be slow. You could perhaps > adjust the cache expiration for your repositories. Does this happen > everytime you do -U or just the first time after a while? > > On Mon, Aug 24, 2009 at 7:30 AM, Mark Hobson<markhobson@...> wrote: >> 2009/8/20 Mark Hobson <markhobson@...>: >>> Hi there, >>> >>> I've set up a route to match internal artifacts that only checks our >>> internally hosted repositories. The problem is that Maven still takes >>> about one second per snapshot when checking for updates using -U. Is >>> there anything I'm missing? I tried setting the log level to debug >>> but I couldn't see any routing messages that stated which repositories >>> where being checked. >> >> Any tips here? I saw from the similar thread that 1.4 will help >> diagnose these problems. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> For additional commands, e-mail: nexus-user-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: nexus-user-unsubscribe@... > For additional commands, e-mail: nexus-user-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Damian Bradicich
::
Rate this Message:
Hi Mark, yes using maven to deploy to nexus is definitely the best move, as it will properly update the NFC, indexes, etc.
And here is a link to the book (should be a link to it still from the maven book though)
Damian
On Mon, Aug 24, 2009 at 9:22 AM, Mark Hobson <markhobson@...> wrote: Hmm yes, sorry, I forgot that I had to adjust the 'not found cache |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
Thanks for the link Damian. I may have missed something, but I
couldn't find a section detailing how to configure Maven to deploy to Nexus? I see the staged deployment section, although this is not applicable since I'm using Nexus OSS. I assume that it's just a matter of changing the distribution management repository URLs to point to the relevant Nexus repositories. Does Nexus accept the standard repo URLs for deployment? e.g. http://<host>/nexus/content/repositories/<repo>/ Cheers, Mark 2009/8/24 Damian Bradicich <dbradicich@...>: > Hi Mark, yes using maven to deploy to nexus is definitely the best move, as > it will properly update the NFC, indexes, etc. > > And here is a link to the book (should be a link to it still from the maven > book though) > > http://www.sonatype.com/books/nexus-book/reference/ > > Damian > > On Mon, Aug 24, 2009 at 9:22 AM, Mark Hobson <markhobson@...> wrote: >> >> Hmm yes, sorry, I forgot that I had to adjust the 'not found cache >> TTL' to one minute for our internal snapshot and release repos to >> workaround this issue: >> >> >> http://www.nabble.com/Re%3A-Item-not-found-for-UID...message-for-SNAPSHOT-artifacts-on--Solaris-td23273378ef34835.html >> >> It does happen every time I do a -U. >> >> So is the best solution to configure Maven to deploy directly to >> Nexus, allowing the negative cache to be upped? I tried to check the >> Nexus documentation but it appears to have moved out from "Maven: The >> Definitive Guide". Any idea where to? >> >> Cheers, >> >> Mark >> >> 2009/8/24 Brian Fox <brianf@...>: >> > There's no obvious reason why this would be slow. You could perhaps >> > adjust the cache expiration for your repositories. Does this happen >> > everytime you do -U or just the first time after a while? >> > >> > On Mon, Aug 24, 2009 at 7:30 AM, Mark Hobson<markhobson@...> >> > wrote: >> >> 2009/8/20 Mark Hobson <markhobson@...>: >> >>> Hi there, >> >>> >> >>> I've set up a route to match internal artifacts that only checks our >> >>> internally hosted repositories. The problem is that Maven still takes >> >>> about one second per snapshot when checking for updates using -U. Is >> >>> there anything I'm missing? I tried setting the log level to debug >> >>> but I couldn't see any routing messages that stated which repositories >> >>> where being checked. >> >> >> >> Any tips here? I saw from the similar thread that 1.4 will help >> >> diagnose these problems. >> >> >> >> Mark >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> >> For additional commands, e-mail: nexus-user-help@... >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: nexus-user-unsubscribe@... >> > For additional commands, e-mail: nexus-user-help@... >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> For additional commands, e-mail: nexus-user-help@... >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Damian Bradicich
::
Rate this Message:
Yes, you'll simply need to setup as follows
(in your settings.xml)
need a <server> entry for your nexus server, which will add a username and password (assuming nexus configured as default out of the box, obviously if you have modified the security, you should use different user/pass here)
<server>
<id>nexus</id>
<username>deployment</username>
<password>deployment123</password>
</server>
Then in your project's pom file, simply reference the same server id in your <distributionManagement>
i.e.
<distributionManagement>
<repository>
<id>nexus</id>
</repository>
<snapshotRepository>
<id>nexus</id>
</snapshotRepository>
</distributionManagement>
Hope that gets you going
Damian
On Tue, Aug 25, 2009 at 5:30 AM, Mark Hobson <markhobson@...> wrote: Thanks for the link Damian. I may have missed something, but I |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
Thanks for that. I've given it a go and can successfully deploy to
Nexus, so I've restored the NFC TTL on our release and snapshot repos to 1440. Unfortunately it's still taking about a second per snapshot every time I run Maven with -U. This makes me think that the routing is not being applied, since even if we neglect the NFC, checking two WebDAV repos hosted on the same machine shouldn't take a whole second. Any ideas? Cheers, Mark 2009/8/25 Damian Bradicich <dbradicich@...>: > Yes, you'll simply need to setup as follows > > (in your settings.xml) > need a <server> entry for your nexus server, which will add a username and > password (assuming nexus configured as default out of the box, obviously if > you have modified the security, you should use different user/pass here) > <server> > <id>nexus</id> > <username>deployment</username> > <password>deployment123</password> > </server> > Then in your project's pom file, simply reference the same server id in your > <distributionManagement> > > i.e. > > <distributionManagement> > <repository> > <id>nexus</id> > <url>http://localhost:8081/nexus/content/repositories/releases</url> > </repository> > <snapshotRepository> > <id>nexus</id> > <url>http://localhost:8081/nexus/content/repositories/snapshots</url> > </snapshotRepository> > </distributionManagement> > > Hope that gets you going > > Damian > > On Tue, Aug 25, 2009 at 5:30 AM, Mark Hobson <markhobson@...> wrote: >> >> Thanks for the link Damian. I may have missed something, but I >> couldn't find a section detailing how to configure Maven to deploy to >> Nexus? I see the staged deployment section, although this is not >> applicable since I'm using Nexus OSS. >> >> I assume that it's just a matter of changing the distribution >> management repository URLs to point to the relevant Nexus >> repositories. Does Nexus accept the standard repo URLs for >> deployment? e.g. http://<host>/nexus/content/repositories/<repo>/ >> >> Cheers, >> >> Mark >> >> 2009/8/24 Damian Bradicich <dbradicich@...>: >> > Hi Mark, yes using maven to deploy to nexus is definitely the best move, >> > as >> > it will properly update the NFC, indexes, etc. >> > >> > And here is a link to the book (should be a link to it still from the >> > maven >> > book though) >> > >> > http://www.sonatype.com/books/nexus-book/reference/ >> > >> > Damian >> > >> > On Mon, Aug 24, 2009 at 9:22 AM, Mark Hobson <markhobson@...> >> > wrote: >> >> >> >> Hmm yes, sorry, I forgot that I had to adjust the 'not found cache >> >> TTL' to one minute for our internal snapshot and release repos to >> >> workaround this issue: >> >> >> >> >> >> >> >> http://www.nabble.com/Re%3A-Item-not-found-for-UID...message-for-SNAPSHOT-artifacts-on--Solaris-td23273378ef34835.html >> >> >> >> It does happen every time I do a -U. >> >> >> >> So is the best solution to configure Maven to deploy directly to >> >> Nexus, allowing the negative cache to be upped? I tried to check the >> >> Nexus documentation but it appears to have moved out from "Maven: The >> >> Definitive Guide". Any idea where to? >> >> >> >> Cheers, >> >> >> >> Mark >> >> >> >> 2009/8/24 Brian Fox <brianf@...>: >> >> > There's no obvious reason why this would be slow. You could perhaps >> >> > adjust the cache expiration for your repositories. Does this happen >> >> > everytime you do -U or just the first time after a while? >> >> > >> >> > On Mon, Aug 24, 2009 at 7:30 AM, Mark Hobson<markhobson@...> >> >> > wrote: >> >> >> 2009/8/20 Mark Hobson <markhobson@...>: >> >> >>> Hi there, >> >> >>> >> >> >>> I've set up a route to match internal artifacts that only checks >> >> >>> our >> >> >>> internally hosted repositories. The problem is that Maven still >> >> >>> takes >> >> >>> about one second per snapshot when checking for updates using -U. >> >> >>> Is >> >> >>> there anything I'm missing? I tried setting the log level to debug >> >> >>> but I couldn't see any routing messages that stated which >> >> >>> repositories >> >> >>> where being checked. >> >> >> >> >> >> Any tips here? I saw from the similar thread that 1.4 will help >> >> >> diagnose these problems. >> >> >> >> >> >> Mark >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> >> >> For additional commands, e-mail: nexus-user-help@... >> >> >> >> >> >> >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: nexus-user-unsubscribe@... >> >> > For additional commands, e-mail: nexus-user-help@... >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> >> For additional commands, e-mail: nexus-user-help@... >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> For additional commands, e-mail: nexus-user-help@... >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Brian Fox
::
Rate this Message:
Is this a public project we could checkout and try? What do the maven
and nexus debug logs show when you do this? On Tue, Aug 25, 2009 at 11:30 AM, Mark Hobson<markhobson@...> wrote: > Thanks for that. I've given it a go and can successfully deploy to > Nexus, so I've restored the NFC TTL on our release and snapshot repos > to 1440. Unfortunately it's still taking about a second per snapshot > every time I run Maven with -U. > > This makes me think that the routing is not being applied, since even > if we neglect the NFC, checking two WebDAV repos hosted on the same > machine shouldn't take a whole second. > > Any ideas? > > Cheers, > > Mark > > 2009/8/25 Damian Bradicich <dbradicich@...>: >> Yes, you'll simply need to setup as follows >> >> (in your settings.xml) >> need a <server> entry for your nexus server, which will add a username and >> password (assuming nexus configured as default out of the box, obviously if >> you have modified the security, you should use different user/pass here) >> <server> >> <id>nexus</id> >> <username>deployment</username> >> <password>deployment123</password> >> </server> >> Then in your project's pom file, simply reference the same server id in your >> <distributionManagement> >> >> i.e. >> >> <distributionManagement> >> <repository> >> <id>nexus</id> >> <url>http://localhost:8081/nexus/content/repositories/releases</url> >> </repository> >> <snapshotRepository> >> <id>nexus</id> >> <url>http://localhost:8081/nexus/content/repositories/snapshots</url> >> </snapshotRepository> >> </distributionManagement> >> >> Hope that gets you going >> >> Damian >> >> On Tue, Aug 25, 2009 at 5:30 AM, Mark Hobson <markhobson@...> wrote: >>> >>> Thanks for the link Damian. I may have missed something, but I >>> couldn't find a section detailing how to configure Maven to deploy to >>> Nexus? I see the staged deployment section, although this is not >>> applicable since I'm using Nexus OSS. >>> >>> I assume that it's just a matter of changing the distribution >>> management repository URLs to point to the relevant Nexus >>> repositories. Does Nexus accept the standard repo URLs for >>> deployment? e.g. http://<host>/nexus/content/repositories/<repo>/ >>> >>> Cheers, >>> >>> Mark >>> >>> 2009/8/24 Damian Bradicich <dbradicich@...>: >>> > Hi Mark, yes using maven to deploy to nexus is definitely the best move, >>> > as >>> > it will properly update the NFC, indexes, etc. >>> > >>> > And here is a link to the book (should be a link to it still from the >>> > maven >>> > book though) >>> > >>> > http://www.sonatype.com/books/nexus-book/reference/ >>> > >>> > Damian >>> > >>> > On Mon, Aug 24, 2009 at 9:22 AM, Mark Hobson <markhobson@...> >>> > wrote: >>> >> >>> >> Hmm yes, sorry, I forgot that I had to adjust the 'not found cache >>> >> TTL' to one minute for our internal snapshot and release repos to >>> >> workaround this issue: >>> >> >>> >> >>> >> >>> >> http://www.nabble.com/Re%3A-Item-not-found-for-UID...message-for-SNAPSHOT-artifacts-on--Solaris-td23273378ef34835.html >>> >> >>> >> It does happen every time I do a -U. >>> >> >>> >> So is the best solution to configure Maven to deploy directly to >>> >> Nexus, allowing the negative cache to be upped? I tried to check the >>> >> Nexus documentation but it appears to have moved out from "Maven: The >>> >> Definitive Guide". Any idea where to? >>> >> >>> >> Cheers, >>> >> >>> >> Mark >>> >> >>> >> 2009/8/24 Brian Fox <brianf@...>: >>> >> > There's no obvious reason why this would be slow. You could perhaps >>> >> > adjust the cache expiration for your repositories. Does this happen >>> >> > everytime you do -U or just the first time after a while? >>> >> > >>> >> > On Mon, Aug 24, 2009 at 7:30 AM, Mark Hobson<markhobson@...> >>> >> > wrote: >>> >> >> 2009/8/20 Mark Hobson <markhobson@...>: >>> >> >>> Hi there, >>> >> >>> >>> >> >>> I've set up a route to match internal artifacts that only checks >>> >> >>> our >>> >> >>> internally hosted repositories. The problem is that Maven still >>> >> >>> takes >>> >> >>> about one second per snapshot when checking for updates using -U. >>> >> >>> Is >>> >> >>> there anything I'm missing? I tried setting the log level to debug >>> >> >>> but I couldn't see any routing messages that stated which >>> >> >>> repositories >>> >> >>> where being checked. >>> >> >> >>> >> >> Any tips here? I saw from the similar thread that 1.4 will help >>> >> >> diagnose these problems. >>> >> >> >>> >> >> Mark >>> >> >> >>> >> >> >>> >> >> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >>> >> >> For additional commands, e-mail: nexus-user-help@... >>> >> >> >>> >> >> >>> >> > >>> >> > --------------------------------------------------------------------- >>> >> > To unsubscribe, e-mail: nexus-user-unsubscribe@... >>> >> > For additional commands, e-mail: nexus-user-help@... >>> >> > >>> >> > >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >>> >> For additional commands, e-mail: nexus-user-help@... >>> >> >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: nexus-user-unsubscribe@... >>> For additional commands, e-mail: nexus-user-help@... >>> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: nexus-user-unsubscribe@... > For additional commands, e-mail: nexus-user-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
I'm afraid it's not public. The Maven logs for 'mvn -U compile' are
as normal, checking for snapshots every second: [INFO] snapshot X:Y:Z-SNAPSHOT: checking for updates from central ... Where central is mirrored to Nexus in settings.xml: <settings> ... <mirrors> <mirror> <id>nexus</id> <name>nexus</name> <url>https://X/nexus/content/groups/Y</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors> <profiles> <profile> <id>nexus</id> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>central</id> <url>http://dummy</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>central</id> <url>http://dummy</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> </settings> The Nexus logs then show this for each requested snapshot: 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - REQUEST /nexus/content/groups/X/Y/Z/maven-metadata.xml on org.mortbay.jetty.HttpConnection@abbd66 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - sessionManager=org.mortbay.jetty.servlet.HashSessionManager@12d3eb2 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - session=null 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - servlet=nexus 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - chain=nexusFilter->nexus 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - servlet holder=nexus 2009-09-02 10:44:36 DEBUG [en-metadata.xml] - org.mortbay.log - call filter nexusFilter 2009-09-02 10:44:37 INFO [en-metadata.xml] - o.s.n.s.f.a.NexusSe~ - Successfully authenticated user [mark] from address/host [192.168.20.182/192.168.20.182] 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.e.Authenticat~:default - Notifying 1 EventListener about event org.sonatype.nexus.auth.NexusAuthenticationEvent fired (org.sonatype.nexus.auth.NexusAuthenticationEvent@1debe48) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - getTargetsForRequest() :: X:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.t.TargetReg~:default - Resolving targets for repository='X' for path='/Y/Z/maven-metadata.xml' 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.a.NexusItem~:default - Checking isPermitted() with perms: [nexus:target:3:X:read, nexus:target:1:X:read, nexus:target:4:X:read] 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - org.mortbay.log - call servlet nexus 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.p.r.r.ManagedPl~:content - Created ResourceStore request for /groups/X/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - getTargetsForRequest() :: X:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.t.TargetReg~:default - Resolving targets for repository='X' for path='/Y/Z/maven-metadata.xml' 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.a.NexusItem~:default - Checking isPermitted() with perms: [nexus:target:4:X:read, nexus:target:3:X:read, nexus:target:1:X:read] 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - retrieveItem() :: X:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.m.RequestRe~:default - Request path for [/Y/Z/maven-metadata.xml] is MAPPED! 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - retrieveItem() :: snapshots:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - snapshots:/Y/Z/maven-metadata.xml :: localOnly=false, remoteOnly=false 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.s.l.LocalRe~:file - /Y/Z/maven-metadata.xml --> /srv/www/maven/snapshots/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.a.Attribute~:default - Loading attributes on UID=snapshots:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml found in local storage. 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml does exist locally and cannot go remote, returning local one. 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - Notifying 1 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve fired (org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve@1d83a3e) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repositor~:default - Notifying 4 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve fired (org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve@1d83a3e) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - snapshots retrieveItem() :: FOUND snapshots:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - retrieveItem() :: releases:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - The path /Y/Z/maven-metadata.xml is in NFC and still active, throwing ItemNotFoundException. 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - storeItem() :: X:/Y/Z/maven-metadata.xml.md5 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.s.l.LocalRe~:file - /Y/Z/maven-metadata.xml.md5 --> /srv/www/maven/nexus-data/storage/X/Y/Z/maven-metadata.xml.md5 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.a.Attribute~:default - Storing attributes on UID=X:/Y/Z/maven-metadata.xml.md5 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - Notifying 1 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventStore fired (org.sonatype.nexus.proxy.events.RepositoryItemEventStore@166b8af) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repositor~:default - Notifying 4 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventStore fired (org.sonatype.nexus.proxy.events.RepositoryItemEventStore@166b8af) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - storeItem() :: X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.s.l.LocalRe~:file - /Y/Z/maven-metadata.xml.sha1 --> /srv/www/maven/nexus-data/storage/X/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.a.Attribute~:default - Storing attributes on UID=X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - Notifying 1 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventStore fired (org.sonatype.nexus.proxy.events.RepositoryItemEventStore@e44482) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repositor~:default - Notifying 4 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventStore fired (org.sonatype.nexus.proxy.events.RepositoryItemEventStore@e44482) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml merged from 1 found items. 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - Notifying 1 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve fired (org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve@4dd51d) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repositor~:default - Notifying 4 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve fired (org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve@4dd51d) 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - X retrieveItem() :: FOUND X:/Y/Z/maven-metadata.xml 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - org.mortbay.log - RESPONSE /nexus/content/groups/X/Y/Z/maven-metadata.xml 200 2009-09-02 10:44:37 DEBUG [qtp0-282 ] - org.mortbay.log - EXCEPTION java.nio.channels.ClosedChannelException at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:125) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:294) at org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:169) at org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:221) at org.mortbay.jetty.security.SslHttpChannelEndPoint.flush(SslHttpChannelEndPoint.java:484) at org.mortbay.jetty.security.SslHttpChannelEndPoint.fill(SslHttpChannelEndPoint.java:329) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:285) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) 2009-09-02 10:44:37 DEBUG [qtp0-282 ] - org.mortbay.log - EOF 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - REQUEST /nexus/content/groups/X/Y/Z/maven-metadata.xml.sha1 on org.mortbay.jetty.HttpConnection@fe9a41 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - sessionManager=org.mortbay.jetty.servlet.HashSessionManager@12d3eb2 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - session=null 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - servlet=nexus 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - chain=nexusFilter->nexus 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - servlet holder=nexus 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - call filter nexusFilter 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.e.Authenticat~:default - Notifying 1 EventListener about event org.sonatype.nexus.auth.NexusAuthenticationEvent fired (org.sonatype.nexus.auth.NexusAuthenticationEvent@1416183) 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.GroupRepo~:maven2 - getTargetsForRequest() :: X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.t.TargetReg~:default - Resolving targets for repository='X' for path='/Y/Z/maven-metadata.xml.sha1' 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.a.NexusItem~:default - Checking isPermitted() with perms: [nexus:target:4:X:read, nexus:target:3:X:read, nexus:target:1:X:read] 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - call servlet nexus 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.p.r.r.ManagedPl~:content - Created ResourceStore request for /groups/X/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.GroupRepo~:maven2 - getTargetsForRequest() :: X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.t.TargetReg~:default - Resolving targets for repository='X' for path='/Y/Z/maven-metadata.xml.sha1' 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.a.NexusItem~:default - Checking isPermitted() with perms: [nexus:target:3:X:read, nexus:target:4:X:read, nexus:target:1:X:read] 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.GroupRepo~:maven2 - retrieveItem() :: X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.s.l.LocalRe~:file - /Y/Z/maven-metadata.xml.sha1 --> /srv/www/maven/nexus-data/storage/X/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.a.Attribute~:default - Loading attributes on UID=X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.GroupRepo~:maven2 - Item X:/Y/Z/maven-metadata.xml.sha1 found in local storage. 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.GroupRepo~:maven2 - Notifying 1 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve fired (org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve@1090e64) 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.Repositor~:default - Notifying 4 EventListener about event org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve fired (org.sonatype.nexus.proxy.events.RepositoryItemEventRetrieve@1090e64) 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - o.s.n.p.r.GroupRepo~:maven2 - X retrieveItem() :: FOUND X:/Y/Z/maven-metadata.xml.sha1 2009-09-02 10:44:37 DEBUG [tadata.xml.sha1] - org.mortbay.log - RESPONSE /nexus/content/groups/X/Y/Z/maven-metadata.xml.sha1 200 Let me know if you need any more info. Thanks, Mark 2009/9/1 Brian Fox <brianf@...>: > Is this a public project we could checkout and try? What do the maven > and nexus debug logs show when you do this? > > On Tue, Aug 25, 2009 at 11:30 AM, Mark Hobson<markhobson@...> wrote: >> Thanks for that. I've given it a go and can successfully deploy to >> Nexus, so I've restored the NFC TTL on our release and snapshot repos >> to 1440. Unfortunately it's still taking about a second per snapshot >> every time I run Maven with -U. >> >> This makes me think that the routing is not being applied, since even >> if we neglect the NFC, checking two WebDAV repos hosted on the same >> machine shouldn't take a whole second. >> >> Any ideas? >> >> Cheers, >> >> Mark >> >> 2009/8/25 Damian Bradicich <dbradicich@...>: >>> Yes, you'll simply need to setup as follows >>> >>> (in your settings.xml) >>> need a <server> entry for your nexus server, which will add a username and >>> password (assuming nexus configured as default out of the box, obviously if >>> you have modified the security, you should use different user/pass here) >>> <server> >>> <id>nexus</id> >>> <username>deployment</username> >>> <password>deployment123</password> >>> </server> >>> Then in your project's pom file, simply reference the same server id in your >>> <distributionManagement> >>> >>> i.e. >>> >>> <distributionManagement> >>> <repository> >>> <id>nexus</id> >>> <url>http://localhost:8081/nexus/content/repositories/releases</url> >>> </repository> >>> <snapshotRepository> >>> <id>nexus</id> >>> <url>http://localhost:8081/nexus/content/repositories/snapshots</url> >>> </snapshotRepository> >>> </distributionManagement> >>> >>> Hope that gets you going >>> >>> Damian >>> >>> On Tue, Aug 25, 2009 at 5:30 AM, Mark Hobson <markhobson@...> wrote: >>>> >>>> Thanks for the link Damian. I may have missed something, but I >>>> couldn't find a section detailing how to configure Maven to deploy to >>>> Nexus? I see the staged deployment section, although this is not >>>> applicable since I'm using Nexus OSS. >>>> >>>> I assume that it's just a matter of changing the distribution >>>> management repository URLs to point to the relevant Nexus >>>> repositories. Does Nexus accept the standard repo URLs for >>>> deployment? e.g. http://<host>/nexus/content/repositories/<repo>/ >>>> >>>> Cheers, >>>> >>>> Mark >>>> >>>> 2009/8/24 Damian Bradicich <dbradicich@...>: >>>> > Hi Mark, yes using maven to deploy to nexus is definitely the best move, >>>> > as >>>> > it will properly update the NFC, indexes, etc. >>>> > >>>> > And here is a link to the book (should be a link to it still from the >>>> > maven >>>> > book though) >>>> > >>>> > http://www.sonatype.com/books/nexus-book/reference/ >>>> > >>>> > Damian >>>> > >>>> > On Mon, Aug 24, 2009 at 9:22 AM, Mark Hobson <markhobson@...> >>>> > wrote: >>>> >> >>>> >> Hmm yes, sorry, I forgot that I had to adjust the 'not found cache >>>> >> TTL' to one minute for our internal snapshot and release repos to >>>> >> workaround this issue: >>>> >> >>>> >> >>>> >> >>>> >> http://www.nabble.com/Re%3A-Item-not-found-for-UID...message-for-SNAPSHOT-artifacts-on--Solaris-td23273378ef34835.html >>>> >> >>>> >> It does happen every time I do a -U. >>>> >> >>>> >> So is the best solution to configure Maven to deploy directly to >>>> >> Nexus, allowing the negative cache to be upped? I tried to check the >>>> >> Nexus documentation but it appears to have moved out from "Maven: The >>>> >> Definitive Guide". Any idea where to? >>>> >> >>>> >> Cheers, >>>> >> >>>> >> Mark >>>> >> >>>> >> 2009/8/24 Brian Fox <brianf@...>: >>>> >> > There's no obvious reason why this would be slow. You could perhaps >>>> >> > adjust the cache expiration for your repositories. Does this happen >>>> >> > everytime you do -U or just the first time after a while? >>>> >> > >>>> >> > On Mon, Aug 24, 2009 at 7:30 AM, Mark Hobson<markhobson@...> >>>> >> > wrote: >>>> >> >> 2009/8/20 Mark Hobson <markhobson@...>: >>>> >> >>> Hi there, >>>> >> >>> >>>> >> >>> I've set up a route to match internal artifacts that only checks >>>> >> >>> our >>>> >> >>> internally hosted repositories. The problem is that Maven still >>>> >> >>> takes >>>> >> >>> about one second per snapshot when checking for updates using -U. >>>> >> >>> Is >>>> >> >>> there anything I'm missing? I tried setting the log level to debug >>>> >> >>> but I couldn't see any routing messages that stated which >>>> >> >>> repositories >>>> >> >>> where being checked. >>>> >> >> >>>> >> >> Any tips here? I saw from the similar thread that 1.4 will help >>>> >> >> diagnose these problems. >>>> >> >> >>>> >> >> Mark >>>> >> >> >>>> >> >> >>>> >> >> --------------------------------------------------------------------- >>>> >> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >>>> >> >> For additional commands, e-mail: nexus-user-help@... >>>> >> >> >>>> >> >> >>>> >> > >>>> >> > --------------------------------------------------------------------- >>>> >> > To unsubscribe, e-mail: nexus-user-unsubscribe@... >>>> >> > For additional commands, e-mail: nexus-user-help@... >>>> >> > >>>> >> > >>>> >> >>>> >> --------------------------------------------------------------------- >>>> >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >>>> >> For additional commands, e-mail: nexus-user-help@... >>>> >> >>>> > >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: nexus-user-unsubscribe@... >>>> For additional commands, e-mail: nexus-user-help@... >>>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> For additional commands, e-mail: nexus-user-help@... >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: nexus-user-unsubscribe@... > For additional commands, e-mail: nexus-user-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Tamás Cservenák
::
Rate this Message:
Hi,
the request processing does hit a Routing rule, that says the log here: 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.m.RequestRe~:default - Request path for [/Y/Z/maven-metadata.xml] is MAPPED! But sadly, the 1.3.x is not so chatty about what Route is mapped. This is completely reworked in 1.4. According to your log, the "snapshots" repository was the only to serve up the metadata you requested, since the group repository "merged" that one only: 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml merged from 1 found items. There was no outbound request (no proxy repository hit), otherwise the log (in DEBUG mode) would show lines with URL being requested from remote. This fact makes even more worrying regarding to response slowness. Interestingly, your "snapshots" repo is a proxy repo (?) and was fresh copy: 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml does exist locally and cannot go remote, returning local one. So, i'd like to see the following: - routing rules you have (but please use correctly the X, Y and Z placeholders, to be able to match them against log) - what security realm you use with Nexus? Is it maybe a bottleneck? - what kind of a OS and more important, what kind of a storage you have "under" Nexus? Thanks, ~t~ On Wed, Sep 2, 2009 at 11:53 AM, Mark Hobson<markhobson@...> wrote: > I'm afraid it's not public. The Maven logs for 'mvn -U compile' are > as normal, checking for snapshots every second: > > [INFO] snapshot X:Y:Z-SNAPSHOT: checking for updates from central > ... --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Tamás Cservenák
::
Rate this Message:
One more question:
- do you go for Jetty embedded in Nexus bundle directly (directly connects to it's HTTP port from client), or there is something (httpd, squid, some other proxy, other sw) in between of Nexus and your Maven CLI? Thanks, ~t~ 2009/9/3 Tamás Cservenák <tamas@...>: > Hi, > > the request processing does hit a Routing rule, that says the log here: > > 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - > o.s.n.p.m.RequestRe~:default - Request path for > [/Y/Z/maven-metadata.xml] is MAPPED! > > But sadly, the 1.3.x is not so chatty about what Route is mapped. This > is completely reworked in 1.4. > > According to your log, the "snapshots" repository was the only to > serve up the metadata you requested, since the group repository > "merged" that one only: > > 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - > o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml > merged from 1 found items. > > There was no outbound request (no proxy repository hit), otherwise the > log (in DEBUG mode) would show lines with URL being requested from > remote. This fact makes even more worrying regarding to response > slowness. Interestingly, your "snapshots" repo is a proxy repo (?) and > was fresh copy: > > 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - > o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml > does exist locally and cannot go remote, returning local one. > > > So, i'd like to see the following: > > - routing rules you have (but please use correctly the X, Y and Z > placeholders, to be able to match them against log) > - what security realm you use with Nexus? Is it maybe a bottleneck? > - what kind of a OS and more important, what kind of a storage you > have "under" Nexus? > > > Thanks, > ~t~ > > On Wed, Sep 2, 2009 at 11:53 AM, Mark Hobson<markhobson@...> wrote: >> I'm afraid it's not public. The Maven logs for 'mvn -U compile' are >> as normal, checking for snapshots every second: >> >> [INFO] snapshot X:Y:Z-SNAPSHOT: checking for updates from central >> ... > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
Hi Tamás,
Thanks for your response and sorry for the delay, I've been on holiday. 2009/9/3 Tamás Cservenák <tamas@...>: > Hi, > > the request processing does hit a Routing rule, that says the log here: > > 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - > o.s.n.p.m.RequestRe~:default - Request path for > [/Y/Z/maven-metadata.xml] is MAPPED! > > But sadly, the 1.3.x is not so chatty about what Route is mapped. This > is completely reworked in 1.4. > > According to your log, the "snapshots" repository was the only to > serve up the metadata you requested, since the group repository > "merged" that one only: > > 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - > o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml > merged from 1 found items. > > There was no outbound request (no proxy repository hit), otherwise the > log (in DEBUG mode) would show lines with URL being requested from > remote. This fact makes even more worrying regarding to response > slowness. Interestingly, your "snapshots" repo is a proxy repo (?) and > was fresh copy: > > 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - > o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml > does exist locally and cannot go remote, returning local one. The 'Snapshots' repo is actually a hosted repository. > So, i'd like to see the following: > > - routing rules you have (but please use correctly the X, Y and Z > placeholders, to be able to match them against log) The only routing rule we have is: URL Pattern: .*/X/.* Rule Type: Inclusive Ordered Route Repositories: Snapshots, Releases > - what security realm you use with Nexus? Is it maybe a bottleneck? We're using the LDAP interface to Active Directory for authentication and the in-built XML security realm for authorization. > - what kind of a OS and more important, what kind of a storage you > have "under" Nexus? We're using OpenSUSE 11 running on an old Dell 750 server with a two disk IDE software RAID1 array. 2009/9/3 Tamás Cservenák <tamas@...>: > One more question: > > - do you go for Jetty embedded in Nexus bundle directly (directly > connects to it's HTTP port from client), or there is something (httpd, > squid, some other proxy, other sw) in between of Nexus and your Maven > CLI? We're using the Nexus Jetty bundle. Thanks for your help, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
Further update to this problem:
We've just upgraded to Nexus OS 1.4 and examined the new route logging. All artifacts are matching the internal routing rules and no external network traffic is occurring. By switching the authentication used, we've discovered that ldaps was taking about five times longer than standard ldap (we're using nexus-ldap [1] and not Nexus Enterprise). So by turning SSL off we've got the time to check snapshot updates down to around the same time as using no authentication. This is all good, but running mvn -U with a project with 102 internal snapshots still takes 20s (no other goals are run here). I'd have expected an almost instantaneous response from Nexus considering they'll all be in the NFC. Does this sound like typical performance, or is something else awry here? Cheers, Mark [1] http://nexus-ldap.googlecode.com/ 2009/9/17 Mark Hobson <markhobson@...>: > Hi Tamás, > > Thanks for your response and sorry for the delay, I've been on holiday. > > 2009/9/3 Tamás Cservenák <tamas@...>: >> Hi, >> >> the request processing does hit a Routing rule, that says the log here: >> >> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >> o.s.n.p.m.RequestRe~:default - Request path for >> [/Y/Z/maven-metadata.xml] is MAPPED! >> >> But sadly, the 1.3.x is not so chatty about what Route is mapped. This >> is completely reworked in 1.4. >> >> According to your log, the "snapshots" repository was the only to >> serve up the metadata you requested, since the group repository >> "merged" that one only: >> >> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >> o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml >> merged from 1 found items. >> >> There was no outbound request (no proxy repository hit), otherwise the >> log (in DEBUG mode) would show lines with URL being requested from >> remote. This fact makes even more worrying regarding to response >> slowness. Interestingly, your "snapshots" repo is a proxy repo (?) and >> was fresh copy: >> >> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >> o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml >> does exist locally and cannot go remote, returning local one. > > The 'Snapshots' repo is actually a hosted repository. > >> So, i'd like to see the following: >> >> - routing rules you have (but please use correctly the X, Y and Z >> placeholders, to be able to match them against log) > > The only routing rule we have is: > > URL Pattern: .*/X/.* > Rule Type: Inclusive > Ordered Route Repositories: Snapshots, Releases > >> - what security realm you use with Nexus? Is it maybe a bottleneck? > > We're using the LDAP interface to Active Directory for authentication > and the in-built XML security realm for authorization. > >> - what kind of a OS and more important, what kind of a storage you >> have "under" Nexus? > > We're using OpenSUSE 11 running on an old Dell 750 server with a two > disk IDE software RAID1 array. > > 2009/9/3 Tamás Cservenák <tamas@...>: >> One more question: >> >> - do you go for Jetty embedded in Nexus bundle directly (directly >> connects to it's HTTP port from client), or there is something (httpd, >> squid, some other proxy, other sw) in between of Nexus and your Maven >> CLI? > > We're using the Nexus Jetty bundle. > > Thanks for your help, > > Mark > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Brian Fox
::
Rate this Message:
Sounds like there's no caching of the credentials occuring in that
ldap module? Each request from Maven coming in gets authenticated since i'm fairly certain the wagon isn't reusing the cookies. On Wed, Nov 4, 2009 at 5:25 AM, Mark Hobson <markhobson@...> wrote: > Further update to this problem: > > We've just upgraded to Nexus OS 1.4 and examined the new route > logging. All artifacts are matching the internal routing rules and no > external network traffic is occurring. By switching the > authentication used, we've discovered that ldaps was taking about five > times longer than standard ldap (we're using nexus-ldap [1] and not > Nexus Enterprise). So by turning SSL off we've got the time to check > snapshot updates down to around the same time as using no > authentication. > > This is all good, but running mvn -U with a project with 102 internal > snapshots still takes 20s (no other goals are run here). I'd have > expected an almost instantaneous response from Nexus considering > they'll all be in the NFC. Does this sound like typical performance, > or is something else awry here? > > Cheers, > > Mark > > [1] http://nexus-ldap.googlecode.com/ > > 2009/9/17 Mark Hobson <markhobson@...>: >> Hi Tamás, >> >> Thanks for your response and sorry for the delay, I've been on holiday. >> >> 2009/9/3 Tamás Cservenák <tamas@...>: >>> Hi, >>> >>> the request processing does hit a Routing rule, that says the log here: >>> >>> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >>> o.s.n.p.m.RequestRe~:default - Request path for >>> [/Y/Z/maven-metadata.xml] is MAPPED! >>> >>> But sadly, the 1.3.x is not so chatty about what Route is mapped. This >>> is completely reworked in 1.4. >>> >>> According to your log, the "snapshots" repository was the only to >>> serve up the metadata you requested, since the group repository >>> "merged" that one only: >>> >>> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >>> o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml >>> merged from 1 found items. >>> >>> There was no outbound request (no proxy repository hit), otherwise the >>> log (in DEBUG mode) would show lines with URL being requested from >>> remote. This fact makes even more worrying regarding to response >>> slowness. Interestingly, your "snapshots" repo is a proxy repo (?) and >>> was fresh copy: >>> >>> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >>> o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml >>> does exist locally and cannot go remote, returning local one. >> >> The 'Snapshots' repo is actually a hosted repository. >> >>> So, i'd like to see the following: >>> >>> - routing rules you have (but please use correctly the X, Y and Z >>> placeholders, to be able to match them against log) >> >> The only routing rule we have is: >> >> URL Pattern: .*/X/.* >> Rule Type: Inclusive >> Ordered Route Repositories: Snapshots, Releases >> >>> - what security realm you use with Nexus? Is it maybe a bottleneck? >> >> We're using the LDAP interface to Active Directory for authentication >> and the in-built XML security realm for authorization. >> >>> - what kind of a OS and more important, what kind of a storage you >>> have "under" Nexus? >> >> We're using OpenSUSE 11 running on an old Dell 750 server with a two >> disk IDE software RAID1 array. >> >> 2009/9/3 Tamás Cservenák <tamas@...>: >>> One more question: >>> >>> - do you go for Jetty embedded in Nexus bundle directly (directly >>> connects to it's HTTP port from client), or there is something (httpd, >>> squid, some other proxy, other sw) in between of Nexus and your Maven >>> CLI? >> >> We're using the Nexus Jetty bundle. >> >> Thanks for your help, >> >> Mark >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: nexus-user-unsubscribe@... > For additional commands, e-mail: nexus-user-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by Anders Hammar
::
Rate this Message:
Yes, nexus-ldap has no explicit caching of the credentials. File an enhancement request (and a patch?) if you need it. But shouldn't Nexus handle that in a generic way for any kind of realm (and I kind of think it does, but I'm not sure)?
However, I did look into a performance issue earlier (see http://code.google.com/p/nexus-ldap/issues/detail?id=11). But that was not related to ldaps. /Anders On Wed, Nov 4, 2009 at 19:20, Brian Fox <brianf@...> wrote: Sounds like there's no caching of the credentials occuring in that |
|
|
Re: Re: Routing internal snapshots
by Brian Fox
::
Rate this Message:
My understanding is jsecurity caches the authentication but not
authorization. This is something we're working on though. On Wed, Nov 4, 2009 at 11:10 AM, Anders Hammar <anders@...> wrote: > Yes, nexus-ldap has no explicit caching of the credentials. File an > enhancement request (and a patch?) if you need it. But shouldn't Nexus > handle that in a generic way for any kind of realm (and I kind of think it > does, but I'm not sure)? > > However, I did look into a performance issue earlier (see > http://code.google.com/p/nexus-ldap/issues/detail?id=11). But that was not > related to ldaps. > > /Anders > > On Wed, Nov 4, 2009 at 19:20, Brian Fox <brianf@...> wrote: >> >> Sounds like there's no caching of the credentials occuring in that >> ldap module? Each request from Maven coming in gets authenticated >> since i'm fairly certain the wagon isn't reusing the cookies. >> >> On Wed, Nov 4, 2009 at 5:25 AM, Mark Hobson <markhobson@...> wrote: >> > Further update to this problem: >> > >> > We've just upgraded to Nexus OS 1.4 and examined the new route >> > logging. All artifacts are matching the internal routing rules and no >> > external network traffic is occurring. By switching the >> > authentication used, we've discovered that ldaps was taking about five >> > times longer than standard ldap (we're using nexus-ldap [1] and not >> > Nexus Enterprise). So by turning SSL off we've got the time to check >> > snapshot updates down to around the same time as using no >> > authentication. >> > >> > This is all good, but running mvn -U with a project with 102 internal >> > snapshots still takes 20s (no other goals are run here). I'd have >> > expected an almost instantaneous response from Nexus considering >> > they'll all be in the NFC. Does this sound like typical performance, >> > or is something else awry here? >> > >> > Cheers, >> > >> > Mark >> > >> > [1] http://nexus-ldap.googlecode.com/ >> > >> > 2009/9/17 Mark Hobson <markhobson@...>: >> >> Hi Tamás, >> >> >> >> Thanks for your response and sorry for the delay, I've been on holiday. >> >> >> >> 2009/9/3 Tamás Cservenák <tamas@...>: >> >>> Hi, >> >>> >> >>> the request processing does hit a Routing rule, that says the log >> >>> here: >> >>> >> >>> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >> >>> o.s.n.p.m.RequestRe~:default - Request path for >> >>> [/Y/Z/maven-metadata.xml] is MAPPED! >> >>> >> >>> But sadly, the 1.3.x is not so chatty about what Route is mapped. This >> >>> is completely reworked in 1.4. >> >>> >> >>> According to your log, the "snapshots" repository was the only to >> >>> serve up the metadata you requested, since the group repository >> >>> "merged" that one only: >> >>> >> >>> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >> >>> o.s.n.p.r.GroupRepo~:maven2 - Item for path /Y/Z/maven-metadata.xml >> >>> merged from 1 found items. >> >>> >> >>> There was no outbound request (no proxy repository hit), otherwise the >> >>> log (in DEBUG mode) would show lines with URL being requested from >> >>> remote. This fact makes even more worrying regarding to response >> >>> slowness. Interestingly, your "snapshots" repo is a proxy repo (?) and >> >>> was fresh copy: >> >>> >> >>> 2009-09-02 10:44:37 DEBUG [en-metadata.xml] - >> >>> o.s.n.p.r.Repository:maven2 - Item snapshots:/Y/Z/maven-metadata.xml >> >>> does exist locally and cannot go remote, returning local one. >> >> >> >> The 'Snapshots' repo is actually a hosted repository. >> >> >> >>> So, i'd like to see the following: >> >>> >> >>> - routing rules you have (but please use correctly the X, Y and Z >> >>> placeholders, to be able to match them against log) >> >> >> >> The only routing rule we have is: >> >> >> >> URL Pattern: .*/X/.* >> >> Rule Type: Inclusive >> >> Ordered Route Repositories: Snapshots, Releases >> >> >> >>> - what security realm you use with Nexus? Is it maybe a bottleneck? >> >> >> >> We're using the LDAP interface to Active Directory for authentication >> >> and the in-built XML security realm for authorization. >> >> >> >>> - what kind of a OS and more important, what kind of a storage you >> >>> have "under" Nexus? >> >> >> >> We're using OpenSUSE 11 running on an old Dell 750 server with a two >> >> disk IDE software RAID1 array. >> >> >> >> 2009/9/3 Tamás Cservenák <tamas@...>: >> >>> One more question: >> >>> >> >>> - do you go for Jetty embedded in Nexus bundle directly (directly >> >>> connects to it's HTTP port from client), or there is something (httpd, >> >>> squid, some other proxy, other sw) in between of Nexus and your Maven >> >>> CLI? >> >> >> >> We're using the Nexus Jetty bundle. >> >> >> >> Thanks for your help, >> >> >> >> Mark >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: nexus-user-unsubscribe@... >> > For additional commands, e-mail: nexus-user-help@... >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: nexus-user-unsubscribe@... >> For additional commands, e-mail: nexus-user-help@... >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
2009/11/4 Anders Hammar <anders@...>:
> Yes, nexus-ldap has no explicit caching of the credentials. File an > enhancement request (and a patch?) if you need it. But shouldn't Nexus > handle that in a generic way for any kind of realm (and I kind of think it > does, but I'm not sure)? > > However, I did look into a performance issue earlier (see > http://code.google.com/p/nexus-ldap/issues/detail?id=11). But that was not > related to ldaps. Thanks, I've raised an issue to track this: http://code.google.com/p/nexus-ldap/issues/detail?id=27 Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
2009/11/4 Brian Fox <brianf@...>:
> My understanding is jsecurity caches the authentication but not > authorization. This is something we're working on though. Is there any Nexus issue I can watch to track this? Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
|
|
Re: Re: Routing internal snapshots
by mihobson
::
Rate this Message:
2009/11/4 Brian Fox <brianf@...>:
> Sounds like there's no caching of the credentials occuring in that > ldap module? Each request from Maven coming in gets authenticated > since i'm fairly certain the wagon isn't reusing the cookies. Even neglecting caching of ldap credentials, when I ran the same process against Nexus using the admin user, with ldap turned off, the process was still relatively slow at just under 20s. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: nexus-user-unsubscribe@... For additional commands, e-mail: nexus-user-help@... |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
