[JBoss JIRA] Commented: (JBWS-670) Provide JMS transport for JAX-WS client
by Wojciech Oczkowski (JIRA)
[ https://jira.jboss.org/jira/browse/JBWS-670?page=com.atlassian.jira.plugi... ]
Wojciech Oczkowski commented on JBWS-670:
-----------------------------------------
anyway, at least timeout value and connection factory name shouldn't be hardcoded.
> Provide JMS transport for JAX-WS client
> ---------------------------------------
>
> Key: JBWS-670
> URL: https://jira.jboss.org/jira/browse/JBWS-670
> Project: JBoss Web Services
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: jbossws-native
> Reporter: Thomas Diesler
>
> Currently, the client will have to use the JMS API directly
> InitialContext context = new InitialContext();
> QueueConnectionFactory connectionFactory = (QueueConnectionFactory)context.lookup("ConnectionFactory");
> Queue reqQueue = (Queue)context.lookup("queue/RequestQueue");
> Queue resQueue = (Queue)context.lookup("queue/ResponseQueue");
> QueueConnection con = connectionFactory.createQueueConnection();
> QueueSession session = con.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
> QueueReceiver receiver = session.createReceiver(resQueue);
> ResponseListener responseListener = new ResponseListener();
> receiver.setMessageListener(responseListener);
> con.start();
> TextMessage message = session.createTextMessage(reqMessage);
> message.setJMSReplyTo(resQueue);
> waitForResponse = true;
>
> QueueSender sender = session.createSender(reqQueue);
> sender.send(message);
> sender.close();
> int timeout = 5000;
> while (waitForResponse && timeout > 0)
> {
> Thread.sleep(100);
> timeout -= 100;
> }
> assertNotNull("Expected response message", responseListener.resMessage);
> assertEquals(DOMUtils.parse(resMessage), DOMUtils.parse(responseListener.resMessage));
> con.stop();
> session.close();
> con.close();
> Instead, the client should use the standard JAX-WS API to consume a wsdl that defines the jms binding
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBWS-1878) ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment
by Wojciech Kudla (JIRA)
ConcurrentModificationException in JAXWS Handler when requests hit JBoss during application deployment
------------------------------------------------------------------------------------------------------
Key: JBWS-1878
URL: http://jira.jboss.com/jira/browse/JBWS-1878
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-jaxws
Affects Versions: jbossws-2.0.1
Environment: AIX 5.3 ppc64, IBM JVM 9 (1.5.0), JBoss 4.2.1.GA with JBossWS 2.0.1.GA
Reporter: Wojciech Kudla
Priority: Critical
When SOAP requests hit JBoss during application deployment they are somewhat queued and get processed just after the application starts. Everything works fine if the are only several requests. If there are more (like 30 or above) before the application starts, HandlerResolverImpl causes ConcurrentModificationException at line 22 (getHandlerChain()).
This exception does not cause the application to stop working, but results in a very strange behaviour, namely: every request goes only through JAXWS Handler twice (on inbound and outbound traffic) but does not hit service implementation (in my case - EJB3 SLSB).
The only clue for me to resolve this problem was to stick to the ConcurrentModificationException and its stacktrace. Going down this path I decided to modify some code in class org.jboss.ws.core.jaxws.handler.HandlerDelegateJAXWS. I synchronized a block of code responsible for initiating handler chains, so the modified method looks like this:
public boolean callRequestHandlerChain(ServerEndpointMetaData sepMetaData, HandlerType type)
{
log.debug("callRequestHandlerChain: " + type);
// Initialize the handler chain
if (isInitialized() == false)
{
synchronized(resolver) {
resolver.initHandlerChain(sepMetaData, HandlerType.PRE, true);
resolver.initHandlerChain(sepMetaData, HandlerType.ENDPOINT, true);
resolver.initHandlerChain(sepMetaData, HandlerType.POST, true);
setInitialized(true);
}
}
HandlerChainExecutor executor = createExecutor(sepMetaData, type);
MessageContext msgContext = (MessageContext)MessageContextAssociation.peekMessageContext();
return executor.handleMessage(msgContext);
}
I tried to do synchronized(this) at the beginning but it very quickly resulted in unstable AS behaviour and stopping JVM with a core dump in the end (SIC!).
Since we are talking about serious production deployment in 5 days (servicing ca. 5000 SOAP requests per hour) , I decided to incorporate my fix into the environment, but I am not completely sure wheter my fix imposes any performance pitfalls.
If you find a better idea to solve this problem, please be quick to publish a solution :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Commented: (JBWS-2615) JBoss does't unload web services classes
by Jeff Gordon (JIRA)
[ https://jira.jboss.org/jira/browse/JBWS-2615?page=com.atlassian.jira.plug... ]
Jeff Gordon commented on JBWS-2615:
-----------------------------------
I hate to throw in a "me too" comment, but I'm at the beginning stages of troubleshooting something similar so I thought I would comment.
I've got an application on JBoss 5.0.1 with 2 sets of deployed web services (a handful of web methods each) that gets hit in our performance testing from another app server and 2 desktop applications (1 using JAX-WS (Sun Metro) on Java 1.5, and 1 using Java 1.6 native implementation). Each web service has a DTO object (Lists of strings mostly with additional Strings and ints in class) and a few Strings as the web service parameters. These all connect to EJB3 stateless session beans along with servlets and timed classes. What we are seeing is that after about 8-10 hours of use the application starts degrading to the point you wouldn't want to use it and at around 20 hours into the test the response time from any call (web service, servlet, or ui) is so slow it would be unusable in a deployed scenario. Anywhere from 1-3 hours later we start getting heap out of memory errors.
Using jhat we see that byte arrays and strings make up the bulk of what's in memory (hundreds of thousands of each) and most of them are owned by the generated "ws" classes. I'm not trying to point any fingers, I just found this issue while searching for some answers and haven't attempted much to resolve the issue except for adding some additional gc parameters. The test was running with:
-Xms256m -Xmx512m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC
I've modified it for troubleshooting to be:
-Xms256m -Xmx1024m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintTenuringDistribution -XX:+TraceClassLoading
At this point I'm leaning toward some of the web service internals not getting cleaned up fast enough as new ones are being made (sorry I can't provide more heap information on this, I'm working on a vanilla method of replication), and I was looking through the issue list to see if there was a newer version of web services I could stick in the app server to try and mitigate the issue.
> JBoss does't unload web services classes
> ----------------------------------------
>
> Key: JBWS-2615
> URL: https://jira.jboss.org/jira/browse/JBWS-2615
> Project: JBoss Web Services
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Windows 2003 Server, JBoss 5.0.0.GA, Java 1.6.0_12.
> Reporter: Edson Goncalez
> Priority: Critical
> Attachments: generated_source_classes.zip, screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg, screenshot-4.jpg
>
>
> We have an application that comunicate with a webservice (Federal Government of Brazil) constantly, step by 5 or 10 seconds.
> We have created web service consumer classes by using the following command point to the WSDL file:
> wsconsume -k -p br.com.compliancefiscal.nfe.ejb.sefaz.ws.nfestatusservico -v NfeStatusServico.wsdl
> This tool, was generated this classes:
> NfeStatusServico.java
> NfeStatusServico_Service.java
> NfeStatusServicoNF.java
> NfeStatusServicoNFResponse.java
> NfeStatusServicoSoap.java
> ObjectFactory.java
> package-info.java
> The problem is. When running... every call this webservice generate a new loadclass. Viewing in the JConsole tool, we can note that whe app starts it have aproximatelly 15000 classes loaded, and afeter 10 hours running we can se that the jvm has increased up to 70000 classes loaded, and only 252 classes unloaded.
> I have the screenshot that show this.
> What can occours to causing this BIG load classes for same class ?
> PS: The app does not run any other service. It just start a method that connect to the specified webservice and return a String info. A TimerService trigger start the process steb by 5 seconds.
> Thanks.
> Edson Gonçalez.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBWS-2649) SOAPMessage implementation bug
by Marcos Prado (JIRA)
SOAPMessage implementation bug
------------------------------
Key: JBWS-2649
URL: https://jira.jboss.org/jira/browse/JBWS-2649
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.5
Environment: JBoss 5.0.1.GA compiled with JDK1.6+Java 6+Windows XP SP2
Reporter: Marcos Prado
Priority: Blocker
Relating to JBWS-1439 issue, I've found the root of the problem:
When you get the exception mentioned:
java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)
at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:83)
at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:161)
I found that the jbossws-native-saaj.jar library has an OVERWRITTEN class javax.xml.soap.SOAPMessage which has overwritten (and not overrided) the method setProperty():
public void setProperty(String property, Object value) throws SOAPException
{
properties.put(property, value);
}
This class is an ABSTRACT class and the specification clearly indicates: setProperty must be overridden by ALL SUBCLASSES of SOAPMessage.
All the javax.xml.soap stuff has been included in the runtime library (rt.jar) in jre 1.6 so, Jboss gives priority to this class and the original one has the next code (as an abstract class) instead of the jbossws-native-saaj.jar one:
public void setProperty(String s, Object obj)
throws SOAPException
{
throw new UnsupportedOperationException("setProperty must be overridden by all subclasses of SOAPMessage");
}
There is an implementation of SOAPMessage in /client/jbossws-native-core.jar, called org.jboss.ws.core.soap.SOAPMessageImpl which extends the SOAPMessage abstract class but, in this case, the rt.jar is the one that has been loaded in the classpath.
This implementation just calls the setProperty() method from his parent... but the parent code is throwing the UnsupporteOperationException!!!
As the specification indicates, the method setProperty that has been overwritten in the jbossws-native-saaj.jar, SOAPMessage class must be in the implementation (subclass), not in the abstract class.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months