[jcifs] WG: Performance Issue with jcifs and NetApp

Torsten Uhr torsten.uhr at sql-ag.de
Mon Jun 10 00:08:59 MDT 2013


Hi,

our customer has used the ListFiles class to do some test again. May be this can be made the situation more clearly.

The conclusion is:
- no properties are set
- the target server name ist 'target.customer.de'
- the domain used to authenticate the user is 'VGM'
- in the resolv.conf (DNS-Serverlist) are two entries: 1st is 'customer.de' and 2nd is 'government.de'

- first a name lookup for 'target.customer.de' is done and the expected result '172.30.40.62' is returned
- than jcifs is building from the (login-) domain a hostname 'VGM.customer.de' and tries to get the address via DNS lookup, which results in 'No such name'
- than jcifs is building from the (login-) domain a hostname 'VGM.government.de' and tries to get the address via DNS lookup, because such a server exists (coincidentally) it results in an IP address '193.30.60.233' but that server is not reachable

Running the test again using an (not existent) domain name of 'VGM2' has proved the description above.
Unfortunately, disabling DFS is not an option for our customer, because they have more SMB servers with a DFS we have to connect to also in the same Java application.

The question for me is: Why jcifs is looking for addresses of name servers prefixed by the login domain after the target server was resolved successfully?


With best regards

Torsten Uhr
Leiter Entwicklung TransConnect®

Email: torsten.uhr at sql-ag.de
Web  : www.transconnect-online.de
·······················································
SQL Projekt AG
Franklinstr. 25 a
01069 Dresden

Aufsichtsratsvorsitzender: Franz-Josef Günther
Vorstand: Jürgen Bittner (Vorsitzender), André Engelhorn, Jens Gärtner
Handelsregister: HRB 28128 Amtsgericht Dresden

Telefon: (0351) 87619-0
Telefax: (0351) 87619-99
http://www.sql-ag.de
······················································· 

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail oder Inhalte ist nicht gestattet. 

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. 
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

ü SAVE PAPER - THINK BEFORE YOU PRINT

-----Ursprüngliche Nachricht-----
Von: Michael B Allen [mailto:ioplex at gmail.com]
Gesendet: Donnerstag, 6. Juni 2013 02:22
An: Torsten Uhr
Cc: jcifs at samba.org
Betreff: Re: [jcifs] Performance Issue with jcifs and NetApp

Copying jcifs list again for posterity ...

On Wed, Jun 5, 2013 at 4:13 AM, Torsten Uhr <torsten.uhr at sql-ag.de> wrote:
>
> Hi Michael,
>
>
>
> because we have more customers using jcfis we want to find out whats the origin problem is. Therefore I have please our customer to run the test only with logging again. Here are the display results.
>
>
>
> Reminder:
>
> ->aaa.aa.aa.aa is the SMB the client is connecting to.
>
> > bbb.bb.bb.bbb is very suspicious! This is a remote (not responding host) The domain, the SMB user is authenticating to is 'VGM'. This is similar to the domain of the dead host. But this is only random! This host is not configured in the client.
>

Hi Torsten,

In the stack trace below we can clearly see JCIFS is trying and failing to do something DFS related. If the host is "not configured"
to access domain VGM as described by your customer above, then there will simply be no way for JCIFS to get a list of DFS roots. Meaning DFS functionality will simply not be possible. But that also means the server probably isn't using DFS anyway. In any case, you should just disable it with:

  jcifs.smb.client.dfs.disabled=true

Arguably JCIFS should be more graceful about handling this condition like having a separate shorter timeout. But currently it looks like this error is triggered with each request which is of course completely illogical and renders the client useless. So DFS in JCIFS only really works in a proper DFS environment. Otherwise, it must be disabled.

So if you just set that one property to disable DFS and use proper fully qualified DNS hostnames, JCIFS it should be fast and fully functional.

Mike

> grztc001:/TransConnect # ./listfiles.sh 
> smb://vgmfas6a.customer.de/VT-Logistik/ VGM Transconnect ******
>
> connected in 55ms
>
> jcifs.smb.SmbException: Failed to connect: VGM/bbb.bb.bb.bbb
>
> jcifs.util.transport.TransportException: Connection timeout
>
>      at jcifs.util.transport.Transport.connect(Transport.java:174)
>
>      at jcifs.smb.SmbTransport.connect(SmbTransport.java:307)
>
>      at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)
>
>      at jcifs.smb.SmbTree.send(SmbTree.java:74)
>
>      at jcifs.smb.SmbTransport.getDfsReferrals(SmbTransport.java:703)
>
>      at jcifs.smb.Dfs.getTrustedDomains(Dfs.java:66)
>
>      at jcifs.smb.Dfs.resolve(Dfs.java:167)
>
>      at jcifs.smb.SmbFile.doConnect(SmbFile.java:902)
>
>      at jcifs.smb.SmbFile.connect(SmbFile.java:954)
>
>      at jcifs.smb.SmbFile.connect0(SmbFile.java:880)
>
>      at jcifs.smb.SmbFile.getType(SmbFile.java:1282)
>
>      at jcifs.smb.SmbFile.doEnum(SmbFile.java:1733)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1715)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1648)
>
>      at ListFiles.main(ListFiles.java:41)
>
>
>
>      at jcifs.smb.SmbTransport.connect(SmbTransport.java:309)
>
>      at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)
>
>      at jcifs.smb.SmbTree.send(SmbTree.java:74)
>
>      at jcifs.smb.SmbTransport.getDfsReferrals(SmbTransport.java:703)
>
>      at jcifs.smb.Dfs.getTrustedDomains(Dfs.java:66)
>
>      at jcifs.smb.Dfs.resolve(Dfs.java:167)
>
>      at jcifs.smb.SmbFile.doConnect(SmbFile.java:902)
>
>      at jcifs.smb.SmbFile.connect(SmbFile.java:954)
>
>      at jcifs.smb.SmbFile.connect0(SmbFile.java:880)
>
>      at jcifs.smb.SmbFile.getType(SmbFile.java:1282)
>
>      at jcifs.smb.SmbFile.doEnum(SmbFile.java:1733)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1715)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1648)
>
>      at ListFiles.main(ListFiles.java:41)
>
> doConnect: vgmfas6a.customer.de/aaa.aa.aa.aa
>
> doFindFirstNext: \
>
> java.net.SocketTimeoutException: connect timed out
>
>      at java.net.PlainSocketImpl.socketConnect(Native Method)
>
>      at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.jav
> a:339)
>
>      at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketI
> mpl.java:200)
>
>      at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:
> 182)
>
>      at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
>
>      at java.net.Socket.connect(Socket.java:579)
>
>      at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:264)
>
>      at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:319)
>
>      at jcifs.util.transport.Transport.run(Transport.java:241)
>
>      at java.lang.Thread.run(Thread.java:722)
>
> jcifs.smb.SmbException: Failed to connect: VGM/bbb.bb.bb.bbb
>
> jcifs.util.transport.TransportException: Connection timeout
>
>      at jcifs.util.transport.Transport.connect(Transport.java:174)
>
>      at jcifs.smb.SmbTransport.connect(SmbTransport.java:307)
>
>      at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)
>
>      at jcifs.smb.SmbTree.send(SmbTree.java:74)
>
>      at jcifs.smb.SmbTransport.getDfsReferrals(SmbTransport.java:703)
>
>      at jcifs.smb.Dfs.getTrustedDomains(Dfs.java:66)
>
>      at jcifs.smb.Dfs.resolve(Dfs.java:167)
>
>      at jcifs.smb.SmbFile.resolveDfs(SmbFile.java:671)
>
>      at jcifs.smb.SmbFile.send(SmbFile.java:773)
>
>      at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:1986)
>
>      at jcifs.smb.SmbFile.doEnum(SmbFile.java:1738)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1715)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1648)
>
>      at ListFiles.main(ListFiles.java:41)
>
>
>
>      at jcifs.smb.SmbTransport.connect(SmbTransport.java:309)
>
>      at jcifs.smb.SmbTree.treeConnect(SmbTree.java:156)
>
>      at jcifs.smb.SmbTree.send(SmbTree.java:74)
>
>      at jcifs.smb.SmbTransport.getDfsReferrals(SmbTransport.java:703)
>
>      at jcifs.smb.Dfs.getTrustedDomains(Dfs.java:66)
>
>      at jcifs.smb.Dfs.resolve(Dfs.java:167)
>
>      at jcifs.smb.SmbFile.resolveDfs(SmbFile.java:671)
>
>      at jcifs.smb.SmbFile.send(SmbFile.java:773)
>
>      at jcifs.smb.SmbFile.doFindFirstNext(SmbFile.java:1986)
>
>      at jcifs.smb.SmbFile.doEnum(SmbFile.java:1738)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1715)
>
>      at jcifs.smb.SmbFile.listFiles(SmbFile.java:1648)
>
>      at ListFiles.main(ListFiles.java:41)
>
> java.net.SocketTimeoutException: connect timed out
>
>      at java.net.PlainSocketImpl.socketConnect(Native Method)
>
>      at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.jav
> a:339)
>
>      at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketI
> mpl.java:200)
>
>      at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:
> 182)
>
>      at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
>
>      at java.net.Socket.connect(Socket.java:579)
>
>      at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:264)
>
>      at jcifs.smb.SmbTransport.doConnect(SmbTransport.java:319)
...snip
> Von: Michael B Allen [mailto:ioplex at gmail.com]
> Gesendet: Dienstag, 4. Juni 2013 17:11
> An: Torsten Uhr
> Cc: jcifs at samba.org
>
>
> Betreff: Re: [jcifs] Performance Issue with jcifs and NetApp
>
>
>
> Copying jcifs again.
>
>
>
> What I see is:
>
>
>
> 36.6s: connect requests and responses are quick
>
> 66.6s: dir listing request response quick
>
> 96.6s: dir listing close request response quick
>
>
>
> So the client is delaying 30 seconds in between each request in the directory listing and possibly on startup. There is no other network communication between these requests.
>
>
>
> If you run with jcifs.util.loglevel=3 and attach the log, I think we would see what is causing the delay. Again, don't use any other properties. If you really want to know what's going on, we just have to go through each diagnostic step. If you want it to just work, then you can use WINS or disable DFS or whatever you need to make it work and move on. No one would fault you for bailing out here.
>
>
>
> Mike
>
>
>
> PS: Incidentally something is pounding on your machine with SYN requests in the port range 7801-7809. Every few seconds there is a burst of 10-20 requests.
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
>
>
>
>
> On Tue, Jun 4, 2013 at 5:15 AM, Torsten Uhr <torsten.uhr at sql-ag.de> wrote:
>
> Hi Michael,
>
>
>
> using qualified DNS hostnames without any properties are running as 
> slow as using short names. I have attached the TCP capture. 
> Unfortunately I don’t what is ‚junk‘ and what‘s not.Von: Michael B 
> Allen [mailto:ioplex at gmail.com]
>
> Gesendet: Montag, 3. Juni 2013 23:05
> An: Torsten Uhr; jcifs at samba.org
>
>
> Betreff: Re: [jcifs] Performance Issue with jcifs and NetApp
>
>
>
> Hi Uhr,
>
>
>
> I'm also sending to the mailing list for posterity (I would CC but gmail is slowly becoming an incomprehensible simplistic POS).
>
>
>
> I have analyzed your capture.
>
>
>
> It seems you are trying to use NetBIOS names and the lookups are failing (unless you specify a WINS server as you have discovered). NetBIOS names are the short one-label hostnames. Do not use NetBIOS names. NetBIOS is virtually all but dead. Even when people use short one-label names they are almost always still using DNS weather they realize it or not because the host resolver is using the builtin domain suffix search feature. But JCIFS does not have the capability to use a domain suffix search. If you use a one-label name, JCIFS will try to do NetBIOS and thus you'll get failure. So you should always use fully qualified DNS hostnames with JCIFS (and all other applications). That might be inconvenient but anything less is simply inaccurate and prone to failure. All real applications should use FQDNs.
>
>
>
> You should not need to disable NTLMv2. If your NetApp server doesn't support NTLMv2, you really should look into updating it because eventually someone is going to disable NTLMv1.
>
>
>
> So take out all of the properties and just try to use a fully qualified DNS hostname in your SMB URL.
>
>
>
> Note that your capture also had a bit of other junk in it. If you send me another capture for some reason, it would be better if you could identify the junk and filter out those ports.
>
>
>
> Mike
>
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
>
>
> On Mon, Jun 3, 2013 at 6:28 AM, Torsten Uhr <torsten.uhr at sql-ag.de> wrote:
>
> Hi Michael,
>
>
>
> attached Your will find two TCP captures. The file ‚with_props.pcap.zip‘ was created using the following jcifs properties:
>
>
>
> export JAVA_OPTS=-Djcifs.smb.lmCompatibility=2
> export JAVA_OPTS=-Djcifs.smb.client.useExtendedSecurity=false
> export JAVA_OPTS=-Djcifs.util.loglevel=3 export 
> JAVA_OPTS=-Djcifs.resolveOrder=DNS
> export JAVA_OPTS=-Djcifs.smb.client.dfs.disabled=true
>
>
>
>
> The file ‚without_props.zip‘ was created using the following jcifs properties:
>
>
>
> export JAVA_OPTS=-Djcifs.smb.lmCompatibility=2
> export JAVA_OPTS=-Djcifs.smb.client.useExtendedSecurity=false
> export JAVA_OPTS=-Djcifs.util.loglevel=3 export 
> JAVA_OPTS=-Djcifs.resolveOrder=LMHOSTS,WINS,DNS
> export JAVA_OPTS=-Djcifs.smb.client.soTimeout=35000
>
>
>
> Surprisingly the following configuration works as fast as expected!!
>
>
>
> export JAVA_OPTS=-Djcifs.smb.lmCompatibility=2
> export JAVA_OPTS=-Djcifs.smb.client.useExtendedSecurity=false
> export JAVA_OPTS=-Djcifs.util.loglevel=3 export 
> JAVA_OPTS=-Djcifs.netbios.wins=193.30.54.5
> export JAVA_OPTS=-Djcifs.smb.client.soTimeout=35000
> export JAVA_OPTS=-Djcifs.resolveOrder=DNS
> export JAVA_OPTS=-Djcifs.smb.client.dfs.disabled=true
>
>
>
> Correcty my if I wrong, but in the last test, if we set 
> ‚jcifs.resolveOrder‘ to ‚DNS‘, why the property
>
> ‚Djcifs.netbios.wins‘ is not ignored?
>
>
>
> With best regards
>
>
>
> Torsten Uhr
>
> Leiter Entwicklung TransConnect®
>
>
>
>
>
>




--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/




More information about the jCIFS mailing list