[jcifs] Performance Issue with jcifs and NetApp

Michael B Allen ioplex at gmail.com
Wed Jun 5 18:22:25 MDT 2013


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.java:339)
>
>      at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.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.java:339)
>
>      at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.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