Created attachment 52060 [details]
Web app with web service that has many operations

This appears to be in wsit code. Reassigning to Martin. Also attached
a a project that has a ws with many operations.

Pls note the fix-in-60 keyword.. meaning the QE is expecting this to be fixed this week by Monday 4pm Prague time.

 Yes, I see the keyword. 

 I wonder if this is just some kind of a stress test, or you really need such a service with 80 operations? From the
wsdl it doesn't look like, as operations are just named operation1-80.

 The thing is that it really takes that long - 80op service is not a small thing. It takes 10-30 seconds on my notebook
and the generated config file is large - ~300kB or 5000 lines (it works reliably, I didn't experience any hangs - using
latest NB build). 

 There is no real problem in the code itself - it does what it should. One way to optimize the generated file would be
by reusing the same input/output message policy for every operation and creating per-operation-specific policies only if
user configures different targets for a specific operation. That would save ~3500 lines, or 230kB of the generated
config file. However, the main feature is to keep interoperability with MS, and in Microsoft interop wsdls, they always
have the policy present for each message and do not reuse policies, so it does require more testing to ensure MS side is
able to consume such WSs without issues.

 The other potential optimization would be a profile feature, which we might introduce in future Metro releases - that
could save even larger portions of the config file.

 I'll see if I can introduce at least some wait cursor in there for 6.0

Adding Lukas to the cc list. Lukas, kindly review if this deserves a 
fix-in-60 keyword. I agree with Martin that a web service with
80 operations is probably a rare corner case. 

I agree with the fact that a websvc with >30 operations is a rare corner case.

What I do not like is that there's no feedback from the IDE (ie. no busy cursor, nothing in progress bar, no progress
bar which would block WS designer,...) - at least this is something what I'd like to see fixed in 6.0.

Sure, as I mentioned, I'll add the modal progress bar. But I do not plan to go into the deeper fixes at this point for
6.0. I will fix it probably right after branching so that we could potentially put it to update center after verifying
all the MS interops.

I added progress dialog. I'm leaving it still open for future tracking. We really need to make this faster.

cvs server: scheduling file `ProgressPanel.form' for addition
cvs server: scheduling file `ProgressPanel.java' for addition
cvs server: use 'cvs commit' to add these files permanently
Checking in wsdlmodelext/PolicyModelHelper.java;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/wsdlmodelext/PolicyModelHelper.java,v  <-- 
PolicyModelHelper.java
new revision: 1.13; previous revision: 1.12
done
Checking in wsdlmodelext/SecurityPolicyModelHelper.java;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/wsdlmodelext/SecurityPolicyModelHelper.java,v  <-- 
SecurityPolicyModelHelper.java
new revision: 1.17; previous revision: 1.16
done
Checking in design/MtomConfiguration.java;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/MtomConfiguration.java,v  <--  MtomConfiguration.java
new revision: 1.12; previous revision: 1.11
done
RCS file: /cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/ProgressPanel.java,v
done
Checking in design/ProgressPanel.java;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/ProgressPanel.java,v  <--  ProgressPanel.java
initial revision: 1.1
done
Checking in design/SecurityConfiguration.java;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/SecurityConfiguration.java,v  <-- 
SecurityConfiguration.java
new revision: 1.21; previous revision: 1.20
done
Checking in design/RMConfiguration.java;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/RMConfiguration.java,v  <--  RMConfiguration.java
new revision: 1.12; previous revision: 1.11
done
RCS file: /cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/ProgressPanel.form,v
done
Checking in design/ProgressPanel.form;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/ProgressPanel.form,v  <--  ProgressPanel.form
initial revision: 1.1
done
Checking in design/Bundle.properties;
/cvs/websvc/wsitconf/src/org/netbeans/modules/websvc/wsitconf/design/Bundle.properties,v  <--  Bundle.properties
new revision: 1.7; previous revision: 1.6
done

thanks for the progress dialog :)

Thanks for the progress dialog! The instability I've noticed when I reported this problem seems had other roots as it is
gone now.

I've got the above mentioned fix ready, seems like it improves the performance to more acceptable level. Will commit to
trunk this week.

The main fix has been delivered, additional fixes are more enhancements in the functionality which need to be agreed
across the board and cross-checked with interop, so changing to enhancement.

moving opened issues where TM != dev to TM=TBD

The agreement has been to not change anything