ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <>
Subject [jira] Commented: (IVY-817) If DNS is playing up, Ivy takes a lot longer to sort project dependencies
Date Fri, 16 May 2008 13:45:55 GMT


Steve Loughran commented on IVY-817:

I have a stack trace, I was right, it really is DNS.

[ivy:resolve] == resolving dependencies org.smartfrog#sf-loggingservices;latest.integration->org.smartfrog#smartfrog;latest.integration
2008-05-16 14:36:23
Full thread dump Java HotSpot(TM) Client VM (10.0-b22 mixed mode, sharing):

"Low Memory Detector" daemon prio=10 tid=0x08097000 nid=0x1ddf runnable [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x0808c400 nid=0x1dde waiting on condition [0x00000000..0xb5a29a78]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x0808b000 nid=0x1ddd waiting on condition [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=10 tid=0x08081c00 nid=0x1ddc in Object.wait() [0xb5b11000..0xb5b11ec0]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x8c4d2e60> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(
	- locked <0x8c4d2e60> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(
	at java.lang.ref.Finalizer$

"Reference Handler" daemon prio=10 tid=0x08080c00 nid=0x1ddb in Object.wait() [0xb5b62000..0xb5b62e40]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x8c4d2ee8> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(
	at java.lang.ref.Reference$
	- locked <0x8c4d2ee8> (a java.lang.ref.Reference$Lock)

"main" prio=10 tid=0x08058c00 nid=0x1dd9 runnable [0xb7dc1000..0xb7dc2218]
   java.lang.Thread.State: RUNNABLE
	at Method)
	at org.apache.ivy.util.HostUtil.getLocalHostName(
	at org.apache.ivy.Ivy.getWorkingRevision(
	at org.apache.ivy.core.sort.ModuleInSort.match(
	at org.apache.ivy.core.sort.CollectionOfModulesToSort.getModuleDescriptorDependency(
	at org.apache.ivy.core.sort.ModuleDescriptorSorter.sortModuleDescriptorsHelp(
	at org.apache.ivy.core.sort.ModuleDescriptorSorter.sortModuleDescriptors(
	at org.apache.ivy.core.sort.SortEngine.sortModuleDescriptors(
	at org.apache.ivy.core.sort.SortEngine.sortNodes(
	at org.apache.ivy.core.resolve.ResolveEngine.getDependencies(
	at org.apache.ivy.core.resolve.ResolveEngine.resolve(
	at org.apache.ivy.core.resolve.ResolveEngine.resolve(
	at org.apache.ivy.Ivy.resolve(
	at org.apache.ivy.ant.IvyResolve.doExecute(
	at org.apache.ivy.ant.IvyTask.execute(
	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(

"VM Thread" prio=10 tid=0x0807f400 nid=0x1dda runnable 

"VM Periodic Task Thread" prio=10 tid=0x080aa800 nid=0x1de0 waiting on condition 

JNI global references: 991

 def new generation   total 960K, used 793K [0x8bfd0000, 0x8c0d0000, 0x8c4b0000)
  eden space 896K,  83% used [0x8bfd0000, 0x8c089f60, 0x8c0b0000)
  from space 64K,  77% used [0x8c0b0000, 0x8c0bc658, 0x8c0c0000)
  to   space 64K,   0% used [0x8c0c0000, 0x8c0c0000, 0x8c0d0000)
 tenured generation   total 4096K, used 3746K [0x8c4b0000, 0x8c8b0000, 0x8ffd0000)
   the space 4096K,  91% used [0x8c4b0000, 0x8c858898, 0x8c858a00, 0x8c8b0000)
 compacting perm gen  total 12288K, used 4757K [0x8ffd0000, 0x90bd0000, 0x93fd0000)
   the space 12288K,  38% used [0x8ffd0000, 0x90475598, 0x90475600, 0x90bd0000)
    ro space 8192K,  73% used [0x93fd0000, 0x945b34a0, 0x945b3600, 0x947d0000)
    rw space 12288K,  58% used [0x947d0000, 0x94ec8668, 0x94ec8800, 0x953d0000)

Its in looking up the local host address. Clearly the networking is in trouble, and this is
a good time for a system rebuild. But 
(a) do you have to look up the hostname
(b) can you cache it?

In SmartFrog we cache it, and we even handle a failure of lookup to resolve any hostname

            try {
                //this can still do a network reverse DNS lookup, and hence fail
                hostInetAddress = InetAddress.getLocalHost();
            } catch (UnknownHostException e) {
                //no, nothing there either
                hostInetAddress = InetAddress.getByName(null);


> If DNS is playing up, Ivy takes a lot longer to sort project dependencies
> -------------------------------------------------------------------------
>                 Key: IVY-817
>                 URL:
>             Project: Ivy
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0.0-beta-2
>         Environment: Ubuntu 8.04 with messed up DNS
>            Reporter: Steve Loughran
> I've just upgraded to Ubuntu 8.04, and for reasons I dont fully understand. DNS is now
very patchy; long pauses before responses coming in
> running at -d level, the pauses happen after printing all the pauses, finishing when
the Sort dependencies response comes in
> [ivy-projects] Module descriptor is processed : org.smartfrog#sf-tasks;working@k2
> [ivy-projects] Module descriptor is processed : org.smartfrog#smartfrog;working@k2
> //insert 30s pause here
> [ivy-projects] Sort dependencies of : org.smartfrog#sf-m32;working@k2 / Number of dependencies
= 9
> During resolution, the delay happens after the sort
> [ivy:resolve] Module descriptor is processed : org.apache.ant#ant;1.7.0
> [ivy:resolve] Sort done for : org.apache.ant#ant-apache-regexp;1.7.0
> [ivy:resolve] Sort dependencies of : org.apache.ant#ant-apache-resolver;1.7.0 / Number
of dependencies = 3
> //here is where the delay is
> [ivy:resolve] Module descriptor is processed : org.apache.ant#ant;1.7.0
> [ivy:resolve] Sort done for : org.apache.ant#ant-apache-resolver;1.7.0
> [ivy:resolve] Sort dependencies of : org.apache.ant#ant-commons-logging;1.7.0 / Number
of dependencies = 3
> -I'm not sure why dns/rdns should be needed during a sort, unless remote repositories
are being polled. I'm also surprised, as java caches DNS responses by default. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message