Anonymous_User Absent Member.
Absent Member.
2936 views

JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

The Setup

OK. I have an interesting problem and I'm not sure if this post is the
appropriate place. I have an application that is web based and runs on
JBOSS and Tomcat on Windows 2000 Server or Windows 20003 Server. The
application is Primavera's Expedition, version 10.1. Normally, the
JBOSS/Tomcat app is set up as a service. The problem is, the are
thousands of files referred to within the application. These files are
called attachments. An attachment reference, in Expedition speak, is
merely a pointer to a file that resides somewhere, whether via URL,
mapped drive, or UNC path.

The Issue

Primavera assumed an all-Windows environment when they rolled out this
new version of Expedition. They assumed all the attachments would be
residing on the web server itself or on another Windows share, and that
they would be accessible via UNC path while the app runs in service
mode. They assumed the account used to run JBOSS/Tomcat would have at
least read access to the attachments. My users are not in a Windows
domain. They run as local users on Windows 2000 Workstation. They save
the files (that the attachment references are mad to from within
Expedition) to a drive mapped to a NetWare 6.5 SP3 volume. The account
on the Windows Server is not going to be able to access the files while
running in service mode. The only semi-working solution I have so far
is to run the app under a user logged in at the console using the latest
Novell client with a drive mapped to the same place my users map for the
attachments.


Proposed Solutions

You may be thinking that Native File Access would solve this. Native
File Access does not seem to be a workable solution for me. You see,
under Native File Access, the server is presented with a name different
from that of its NetWare name. This means that they don't get a Windows
login script. They see the NetWare volume with the mapped drive. If
all the existing trustee assignments would stay in tact then maybe this
would be a possible solution, but so far it seems to be a no go on
making this work in our environment.

Another solution would be to cater to the vendor and place a couple
hundred workstations in to our Windows NT 4 Domain and create all those
user accounts and move 200,000 files to a Windows box and re-create the
user file systems rights on the Windows server share. I hear your
laughter from here.

The only solution I have that kind of works is what I'm doing now -
running the app logged in with the Novell client with a drive mapped.
The problem is that it takes the app six minutes to open a 1MB PDF
file. This same file, opened from the server, opens in seconds. The
user account can move large files in seconds over the network between
itself and the NetWare volumes. The slowdown only happens when the file
is accessed via the web app.

Any thoughts?

Before you ask, the application is JBOSS 3.2.5 and Tomcat 5, running in
tandem on Windows 2000 Server. Running on Linux or NetWare is not an
option, seeing as how the vendor of the app won't support running the
app on either platform and I would have to spend quite a bit of time
reverse-engineering the app to pull it off anyway.

Also, I performed packet captures with Ethereal on the server and client
and merged them together in time sequence order. I see tons of
re-transmissions. I just don't know what to make of it from there. If
anyone is interested I will send them the packet capture.

Labels (1)
0 Likes
10 Replies
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Toby,

Sounds like you have two issues - the service needing access to the
server, and a comms issue causing the retransmissions. For the service
issue take a look at:

http://support.novell.com/cgi-bin/search/searchtid.cgi?10019785.htm

For the comms issue - take a look at the duplex configuration on the
server, workstations and switches - it needs to be set to the same value
at each end of each connection - referably auto negotiate.


--
Hamish Speirs
Novell Support Forums Volunteer Sysop.

http://haitch.net

(Please, no email unless requested. Unsolicited support emails will
probably be ignored)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

All of the network ports are all hard coded to 100/Full.
Autonegotiation is not to be trusted. The setting on both the NetWare
6.5SP3 server and my Windows 2000 Server SP4 test box is hard coded
100/Full. The backbone is Layer 3 routed and runs on gigabit fiber. On
the Windows server where the JBOSS application runs, as the user logged
in at the console, a 138MB file can transfer from the NetWare server to
the Windows server in 21 seconds. That same file can be copied right
back to the NetWare server in 16 seconds. However, connecting to the
JBOSS web app (again, running under the logged in user, not as a
service), and retrieving a 1MB file takes six minutes.

As for the link you posted, I think maybe I haven't provided enough
detailed description of the issue. The application is NOT running as a
service.

I do appreciate the fact that you had a reply and gladly welcome any
other thoughts that you might have. I noticed there is a JBOSS forum,
so I'm going to take this thread and post it as a new message over there.

Hamish Speirs wrote:

> Toby,
>
> Sounds like you have two issues - the service needing access to the
> server, and a comms issue causing the retransmissions. For the service
> issue take a look at:
>
> http://support.novell.com/cgi-bin/search/searchtid.cgi?10019785.htm
>
> For the comms issue - take a look at the duplex configuration on the
> server, workstations and switches - it needs to be set to the same
> value at each end of each connection - referably auto negotiate.
>
>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Toby,

> All of the network ports are all hard coded to 100/Full.
> Autonegotiation is not to be trusted.


Autonegotiation is the only standard for 100/Full. There is no standard
for hardcoding devices too 100/Full - so vendors are free to implement
it any way they like. Hardcoding devices to 100/Full - especially from
different vendors, but even the same vendor - is asking for trouble and
duplex mismatches.

From: http://www.cisco.com/warp/public/473/46.html

"Some third-party NIC cards may fall back to half-duplex operation mode,
even though both the switchport and NIC configuration have been manually
configured for 100 Mbps, full-duplex. This behavior is due to the fact
that NIC autonegotiation link detection is still operating when the NIC
has been manually configured. This causes duplex inconsistency between
the switchport and the NIC. Symptoms include poor port performance and
frame check sequence (FCS) errors that increment on the switchport. To
troubleshoot this issue, try manually configuring the switchport to 100
Mbps, half-duplex. If this action resolves the connectivity problems,
you may be running into this NIC issue. Try updating to the latest
drivers for your NIC, or contact your NIC card vendor for additional
support."

> The setting on both the NetWare
> 6.5SP3 server and my Windows 2000 Server SP4 test box is hard coded
> 100/Full. The backbone is Layer 3 routed and runs on gigabit fiber. On
> the Windows server where the JBOSS application runs, as the user logged
> in at the console, a 138MB file can transfer from the NetWare server to
> the Windows server in 21 seconds. That same file can be copied right
> back to the NetWare server in 16 seconds. However, connecting to the
> JBOSS web app (again, running under the logged in user, not as a
> service), and retrieving a 1MB file takes six minutes.


Have you looked at a packet trace of the login process and the file
transfers to see whats going on during that time period ?

> As for the link you posted, I think maybe I haven't provided enough
> detailed description of the issue. The application is NOT running as a
> service.


My understanding from your post was that you were looking for a way to
run the app as a service.

> I do appreciate the fact that you had a reply and gladly welcome any
> other thoughts that you might have. I noticed there is a JBOSS forum,
> so I'm going to take this thread and post it as a new message over there.


I'd still look at duplex issues - hardcoding 100/Full is asking to get
bitten by duplex issues, and they can manifest themselves in wierd and
wonderful ways.



--
Hamish Speirs
Novell Support Forums Volunteer Sysop.

http://haitch.net

(Please, no email unless requested. Unsolicited support emails will
probably be ignored)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Fluke disagrees with Cisco on autonegotiation. You'll need a Fluke
account to access the file. The article can be found here:

http://www.flukenetworks.com/us/_Promotions/ESV/Autonegotiation+WP+Internal+Splash.htm


Here's another article on 10gbps Ethernet and how the standard will not
include support for autonegotiation:

http://www.itworld.com/Net/1748/NWW010507feat3/

"Another change that's probably welcome is that 802.3ae does not support
autonegotiation, which was intended to be a convenience but in practice
has proven to be a major source of connectivity headaches. The
elimination of autonegotiation is likely to simplify troubleshooting."


And last, but certainly not least, Tolly disagrees with Cisco:

http://www.networkworld.com/columnists/2002/1209tolly.html

"Recently, I had the misfortune of taking autonegotiation for granted.
In a test at The Tolly Group lab facilities, I found out that not all
autonegotiation algorithms are created equal. In this one instance, the
lack of effective autonegotiation resulted in a 66% loss of throughput
between a server and a client PC for no apparent reason."

I'm not surprised that Cisco has misinformed you. We're running several
hundred clients, switch ports, and servers, all hard coded at 100/Full
without error. Cisco is wrong. My real-world experience, working with
this switched, routed, managed network for the last few years, says that
autonegotiation is not to be trusted. Also, my senior network engineer,
who is a CCNE, agrees with Fluke and Tolly, and is the one who hard
coded all the switch ports and had all the workstation ports hard coded.

Hamish Speirs wrote:

> Toby,
>
>> All of the network ports are all hard coded to 100/Full.
>> Autonegotiation is not to be trusted.

>
>
> Autonegotiation is the only standard for 100/Full. There is no
> standard for hardcoding devices too 100/Full - so vendors are free to
> implement it any way they like. Hardcoding devices to 100/Full -
> especially from different vendors, but even the same vendor - is
> asking for trouble and duplex mismatches.
>
> From: http://www.cisco.com/warp/public/473/46.html
>
> "Some third-party NIC cards may fall back to half-duplex operation
> mode, even though both the switchport and NIC configuration have been
> manually configured for 100 Mbps, full-duplex. This behavior is due to
> the fact that NIC autonegotiation link detection is still operating
> when the NIC has been manually configured. This causes duplex
> inconsistency between the switchport and the NIC. Symptoms include
> poor port performance and frame check sequence (FCS) errors that
> increment on the switchport. To troubleshoot this issue, try manually
> configuring the switchport to 100 Mbps, half-duplex. If this action
> resolves the connectivity problems, you may be running into this NIC
> issue. Try updating to the latest drivers for your NIC, or contact
> your NIC card vendor for additional support."
>
>> The setting on both the NetWare 6.5SP3 server and my Windows 2000
>> Server SP4 test box is hard coded 100/Full. The backbone is Layer 3
>> routed and runs on gigabit fiber. On the Windows server where the
>> JBOSS application runs, as the user logged in at the console, a 138MB
>> file can transfer from the NetWare server to the Windows server in 21
>> seconds. That same file can be copied right back to the NetWare
>> server in 16 seconds. However, connecting to the JBOSS web app
>> (again, running under the logged in user, not as a service), and
>> retrieving a 1MB file takes six minutes.

>
>
>
> I'd still look at duplex issues - hardcoding 100/Full is asking to get
> bitten by duplex issues, and they can manifest themselves in wierd and
> wonderful ways.
>
>
>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Well, I take it that attachments are blocked in the forums, so here's
from page 5 of Fluke's document titled "Fixing Ethernet and Fast Ethernet
Link Problems":

Auto-negotiation problem resolution If you discover a network link with
a half/full duplex conflict, there are three typical solutions:

.. Configure both link partners to auto-negotiate
.. Force both link partners to a fixed half duplex configuration
.. Force both link partners to a fixed full duplex configuration

The solution will depend on the equipment involved. If the problem
resulted from careless misconfiguration, then Auto/Auto is perhaps a
safe choice. If the problem resulted from misbehavior on the part of one
device, it may be necessary to experiment with fixed configurations to
find one that permits the link to operate without errors.

To avoid any potential duplex negotiation problems many network
engineers do not allow "Auto/Auto" links on their networks at all. These
engineers have decided that only by explicitly setting both sides of the
link to the same duplex mode can you be certain the link works correctly
and reliably.

Toby Fruth wrote:

> Fluke disagrees with Cisco on autonegotiation. You'll need a Fluke
> account to access the file. The article can be found here:
>
> http://www.flukenetworks.com/us/_Promotions/ESV/Autonegotiation+WP+Internal+Splash.htm
>
>
> Here's another article on 10gbps Ethernet and how the standard will
> not include support for autonegotiation:
>
> http://www.itworld.com/Net/1748/NWW010507feat3/
>
> "Another change that's probably welcome is that 802.3ae does not
> support autonegotiation, which was intended to be a convenience but in
> practice has proven to be a major source of connectivity headaches.
> The elimination of autonegotiation is likely to simplify troubleshooting."
>
>
> And last, but certainly not least, Tolly disagrees with Cisco:
>
> http://www.networkworld.com/columnists/2002/1209tolly.html
>
> "Recently, I had the misfortune of taking autonegotiation for granted.
> In a test at The Tolly Group lab facilities, I found out that not all
> autonegotiation algorithms are created equal. In this one instance,
> the lack of effective autonegotiation resulted in a 66% loss of
> throughput between a server and a client PC for no apparent reason."
>
> I'm not surprised that Cisco has misinformed you. We're running
> several hundred clients, switch ports, and servers, all hard coded at
> 100/Full without error. Cisco is wrong. My real-world experience,
> working with this switched, routed, managed network for the last few
> years, says that autonegotiation is not to be trusted. Also, my
> senior network engineer, who is a CCNE, agrees with Fluke and Tolly,
> and is the one who hard coded all the switch ports and had all the
> workstation ports hard coded.
>
> Hamish Speirs wrote:
>
>> Toby,
>>
>>> All of the network ports are all hard coded to 100/Full.
>>> Autonegotiation is not to be trusted.

>>
>>
>> Autonegotiation is the only standard for 100/Full. There is no
>> standard for hardcoding devices too 100/Full - so vendors are free to
>> implement it any way they like. Hardcoding devices to 100/Full -
>> especially from different vendors, but even the same vendor - is
>> asking for trouble and duplex mismatches.
>>
>> From: http://www.cisco.com/warp/public/473/46.html
>>
>> "Some third-party NIC cards may fall back to half-duplex operation
>> mode, even though both the switchport and NIC configuration have been
>> manually configured for 100 Mbps, full-duplex. This behavior is due
>> to the fact that NIC autonegotiation link detection is still
>> operating when the NIC has been manually configured. This causes
>> duplex inconsistency between the switchport and the NIC. Symptoms
>> include poor port performance and frame check sequence (FCS) errors
>> that increment on the switchport. To troubleshoot this issue, try
>> manually configuring the switchport to 100 Mbps, half-duplex. If this
>> action resolves the connectivity problems, you may be running into
>> this NIC issue. Try updating to the latest drivers for your NIC, or
>> contact your NIC card vendor for additional support."
>>
>>> The setting on both the NetWare 6.5SP3 server and my Windows 2000
>>> Server SP4 test box is hard coded 100/Full. The backbone is Layer 3
>>> routed and runs on gigabit fiber. On the Windows server where the
>>> JBOSS application runs, as the user logged in at the console, a
>>> 138MB file can transfer from the NetWare server to the Windows
>>> server in 21 seconds. That same file can be copied right back to
>>> the NetWare server in 16 seconds. However, connecting to the JBOSS
>>> web app (again, running under the logged in user, not as a service),
>>> and retrieving a 1MB file takes six minutes.

>>
>>
>>
>> I'd still look at duplex issues - hardcoding 100/Full is asking to
>> get bitten by duplex issues, and they can manifest themselves in
>> wierd and wonderful ways.
>>
>>
>>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Toby,

> Fluke disagrees with Cisco on autonegotiation. You'll need a Fluke
> account to access the file. The article can be found here:


My personal experience agrees with cisco.

> Here's another article on 10gbps Ethernet and how the standard will not
> include support for autonegotiation:


whereas 1Gbps is auto negotiation only. Different rules for diferent
standards.

> "Recently, I had the misfortune of taking autonegotiation for granted.
> In a test at The Tolly Group lab facilities, I found out that not all
> autonegotiation algorithms are created equal. In this one instance, the
> lack of effective autonegotiation resulted in a 66% loss of throughput
> between a server and a client PC for no apparent reason."


Agreed - auto negotiation is not fool proof - but it IS the only
standard for 100 FD. I've had the misfortune to deal with IBM server and
Cisco switches that handled hard coded 100 FD differently - the result
was throughput around that of 28.8K modem - around a 99.98% throughput
drop. Setting to 100HD or auto negotiate on both ends gave appropriate
throughput for 100HD and 100FD.

> I'm not surprised that Cisco has misinformed you.


They haven't.

> We're running several hundred clients, switch ports, and servers, all hard coded at 100/Full
> without error.


You're lucky then.

> Cisco is wrong.


No.

> My real-world experience, working with this switched, routed, managed network for the last few years, says that
> autonegotiation is not to be trusted.


My real world experience dealing with thousands of servers, switches,
routers, and 10's of thousands client workstations is that hard coding
100FD will bite you bad.

Use auto negotiate
- If you have negotiation issues, update firmware & drivers
- If you still have negotiation issues, test out 100FD hard coded if
you're willing to live a little dangerously, otherwise hard code to
100HD - or swap equipment.

> Also, my senior network engineer,
> who is a CCNE, agrees with Fluke and Tolly, and is the one who hard
> coded all the switch ports and had all the workstation ports hard coded.


Which will work fine until you get a device that doesn't use a
compatible method for dealing with hardcoding.

The common methods for 100FD hard coded seem to be:
- 100FD is what I will do - ignore everything on the NWAY negotiation,
send no NWAY negotiation
- Even though hard coded I will do NWAY autonegotiation.
- I'll do 100FD if I see an NWAY signal from my link partner - otherwise
I'll assume 100HD - I may or may not participate in NWAY negotiation and
I may or may not honor any negotiation.

Guess what happens when you connect a device using the first method to a
device using the last?

If you manage to get device that conform to the same scheme, you *may*
get 100FD when configuring 100FD - then again, you may get connections
that silently fall back to 100HD. But as the IEEE says - the only
standard is NWAY negotiation - use anything else at your risk.


--
Hamish Speirs
Novell Support Forums Volunteer Sysop.

http://haitch.net

(Please, no email unless requested. Unsolicited support emails will
probably be ignored)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Toby,

> • Configure both link partners to auto-negotiate
> • Force both link partners to a fixed half duplex configuration
> • Force both link partners to a fixed full duplex configuration


And that would be my order of preference for configuring links.


--
Hamish Speirs
Novell Support Forums Volunteer Sysop.

http://haitch.net

(Please, no email unless requested. Unsolicited support emails will
probably be ignored)
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Hi,

> Toby Fruth wrote:
>
> Fluke disagrees with Cisco on autonegotiation.


Then Fluke is dead wrong.

CU,
--
Massimo Rosen
Novell Support Connection Sysop
No emails please!
http://www.cfc-it.de
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

To say that Fluke outright disagrees with Cisco may be a little harsh,
but I'll quote Fluke document again (emphasis is mine):

Auto-negotiation problem resolution If you discover a network link with
a half/full duplex conflict, there are three typical solutions:

.. Configure both link partners to auto-negotiate
.. Force both link partners to a fixed half duplex configuration
.. Force both link partners to a fixed full duplex configuration

The solution will depend on the equipment involved. If the problem
resulted from careless misconfiguration, then Auto/Auto is perhaps a
safe choice. If the problem resulted from misbehavior on the part of one
device, it may be necessary to experiment with fixed configurations to
find one that permits the link to operate without errors.

*To avoid any potential duplex negotiation problems many network
engineers do not allow "Auto/Auto" links on their networks at all. These
engineers have decided that only by explicitly setting both sides of the
link to the same duplex mode can you be certain the link works correctly
and reliably.*

Massimo Rosen wrote:

>Hi,
>
>
>
>>Toby Fruth wrote:
>>
>>Fluke disagrees with Cisco on autonegotiation.
>>
>>

>
>Then Fluke is dead wrong.
>
>CU,
>
>


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: JBOSS, 4.91SP1 client, Windows 2003 Server, and NetWare 6.5 Files

Hi,

> Toby Fruth wrote:
>
> • Configure both link partners to auto-negotiate


According to the 100BaseTX standard, this *must* work. If it doesn't one
device is faulty.

> • Force both link partners to a fixed half duplex configuration


According to the 100BaseTX standard, this *must* work. If it doesn't one
device is faulty.

> • Force both link partners to a fixed full duplex configuration


This is not part of *any* official spec, so if it works or not is a game
of luck, and if it doesn't, nobody is to blame. And there *are* real
world configurations (see the Cisco quote posted by Hamish earlier),
where it 100% reliably fails. <g>

> The solution will depend on the equipment involved.


Correct. And usually (+90%), the solutions if autoneg fails is to
indentify and replace the broken piece, but *not* to switch to manual
configuration, cause more often than not this will only mask the
underlying problem (which is almost never a problem with Autonegotiation
per se).

> If the problem
> resulted from careless misconfiguration, then Auto/Auto is perhaps a
> safe choice. If the problem resulted from misbehavior on the part of
> one device, it may be necessary to...


replace that device, because it's either broken, or doesn't adhere to
the standard it's supposed to.

> experiment with fixed
> configurations to find one that permits the link to operate without
> errors.


Only as an absolute last resort if all else fails or isn't feasible.

> To avoid any potential duplex negotiation problems many network
> engineers do not allow “Auto/Auto” links on their networks at all.


True. Which is bad enough, as all these "engineers" have no clue, and
have never read the specs.

> These engineers have decided that only by explicitly setting both
> sides of the link to the same duplex mode can you be certain the link
> works correctly and reliably.


Which is provable wrong, and that's the core point. Manual configuration
to FD is *by far* the most likely configuration to fail.

CU,
--
Massimo Rosen
Novell Support Connection Sysop
No emails please!
http://www.cfc-it.de
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.