how can i set timeout for JAXWS client, Im using Jboss 5.1.
I was trying to do this with
bp.getRequestContext().put("com.sun.xml.ws.connect.timeout", 100);
bp.getRequestContext().put("com.sun.xml.ws.request.timeout", 100);
but it doesn't works. It works fine for standalone client.
When i tried to use
bp.getRequestContext().put("com.sun.xml.ws.request.timeout", 100);
I.ve got org.jboss.ws.core.WSTimeoutException: Timeout after: 100ms, but it is heppening after 300 (3*100 ms).
Can anyone help me with this issue.
While this looks likely to be an oversight on your part, The settings for JAX-WS timeouts might depend on the specific RI you're building on.
You could try these settings (they are paired to be used in pairs)
BindingProviderProperties.REQUEST_TIMEOUT
BindingProviderProperties.CONNECT_TIMEOUT
BindingProviderProperties should be from com.sun.xml.internal.WS.client
Or the strings
javax.xml.ws.client.connectionTimeout
javax.xml.ws.client.receive timeout
All properties to be put on getRequestContext() in milliseconds.
BtW, how were you able to time the milliseconds without code :)?
JAXWS use the JAXB for marshalling and unmarshalling.
In the container probably it's taking more time because it's JAXContext scanning your classpath.
If that's the case try eager initialization of JaxBContext:
JBossWS may perform differently during the first method invocation of
each service and the following ones when huge wsdl contracts (with
hundreds of imported xml schemas) are referenced. This is due to a
bunch of operations performed internally during the first invocation
whose resulting data is then cached and reused during the following
ones. While this is usually not a problem, you might be interested in
having almost the same performance on each invocation. This can be
achieved setting the org.jboss.ws.eagerInitializeJAXBContextCache
system property to true, both on server side (in the JBoss start
script) and on client side (a convenient constant is available in
org.jboss.ws.Constants). The JAXBContext creation is usually
responsible for most of the time required by the stack during the
first invocation; this feature makes JBossWS try to eagerly create and
cache the JAXB contexts before the first invocation is handled.
http://www.mastertheboss.com/javaee/jboss-web-services/web-services-performance-tuning
Related
Context
We use a javax.ws.rs.ext.ExceptionMapper<Exception> annotated as #javax.ws.rs.ext.Provider to handle all exceptions. Internally this ExceptionMapper is distinguishing between different types of exceptions to determine what information to reveal to the client.
In the case of the javax.validation.ConstraintViolationException, we return additional information about which field was invalid and why.
Problem
We just switched from TomEE 1.7.2 JAX-RS to TomEE 7.0.0-SNAPSHOT webprofile.
With TomEE 1.7.2 JAX-RS we used the openejb.jaxrs.providers.auto=true system property, our ExceptionMapper was automatically found and used.
With TomEE 7.0.0-SNAPSHOT webprofile the property is no longer necessary to benefit from auto discovery.
However the org.apache.cxf.jaxrs.validation.ValidationExceptionMapper is also discovered and now acts as the preferred ExceptionMapper for the javax.validation.ConstraintViolationException. Our own ExceptionMapper does not run, and the client therefore gets no information about what went wrong during validation.
Our own ExceptionMapper<Exception> still handles all other exceptions.
What I already tried
"duplicate" the specialized ExceptionMapper
I placed my own javax.ws.rs.ext.ExceptionMapper<javax.validation.ConstraintViolationException> next to my resources, hoping that it takes precedence over the CXF one.
Still the org.apache.cxf.jaxrs.validation.ValidationExceptionMapper takes precedence.
Update: it turned out that this indeed does the trick. I don't know why my initial test didn't work.
Disable the ValidationExceptionMapper via system.properties
In the changelog of TomEE 7.0.0-SNAPSHOT I noticed
TOMEE-1336 Support classname.activated = true/false for auto discovered providers
Looking at the corresponding changeset I was hopeful that I could just disable the org.apache.cxf.jaxrs.validation.ValidationExceptionMapper by adding
org.apache.cxf.jaxrs.validation.ValidationExceptionMapper.activated=false
to our system.properties.
This remained without effect.
Questions
Is this CXF or TomEE behaviour?
How do we configure which ExceptionMapper takes precedence?
Makes some time now but think it is needed by spec but you can disable it by setting cxf.jaxrs.skip-provider-scanning=true.
It completely disables auto providers including the scanned ones but then you can control the one you want in openejb-jar.xml - surely the best and safer solution IMHO cause otherwise you depend a lot of the libs and container setup you use.
There is no priority afaik cause the exception hierarchy is used.
edit: missed a part: you need to impl ExceptionMapper{ValidationException} otherwise CXF one has higher priority than your own one (Exception is less specific)
edit 2: https://issues.apache.org/jira/browse/TOMEE-1656 for the activated support
I read over some articles that tika in server mode improves performance. Can someone explain how? Can we implement similar functionality within our java application for better performance?
Running tika in server mode
In the example you provided when tika is executed as standalone application using jar, there are additional steps that are performed before actually processing pdf file. You can roughly split it to 3:
JVM is instantiated
Tika classes loaded and configured (e.g.: parsers, etc...)
(only then) tika performs content processing
In server mode first two steps are performed on server startup, and it is ready to process files as it receives them.
You can do the same in your application if it performs some processing of input data and the processing time is measurably less that instantiating and configuring the app.
As for implementation you can have a look at tika source code
I looked at the code in TikaServer, only Parser object seems to be initialized. Other Socket related code is not required here. I tried out the code to initialize Parser only once, but didnt see any improvement (for extracting content of 100 files).
So as per vadchen's answer
JVM initialization isn't an issue of a running application; it will anyway happen only once.
Tika initializes Parser object, which doesn't seem to have much impact on performance.
So there isn't any performance improvement as claimed by the article.
I wrote the most simple application that uses WebSockets. My back end is GlassFish 4 build 89, my front end is a JavaFX 2.2 application client that uses Tyrus 1.0 RC3, the reference implementation of Java API for WebSockets. GlassFish uses Tyrus too although I've been to lazy to lookup exactly what version is included in GlassFish build 89.
My test of the WebSocket API sent a java.util.Date back and forth, nothing more. Well, as a binary object should be added. So I wrote my own Decoder that implements Decoder.Binary<Date>. As usual when I enter new fields of knowledge, I like to log each method invocation. And when I looked in the console, it hit me that my Deocer.Binary<Date>#willDecode(ByteBuffer) method was called twice in a row by the same thread! If that really is intentional, what would be the use case for such a pattern, what value was added? But I think it must be a bug! I tried to file a bug/issue over at some GlassFish JIRA site but I didn't find the button anywhere.
not a bug in terms of specification violation (there is no restriction on "willDecode" invocation count), but I agree we should look into it.
progress can be tracked on Tyrus jira, see TYRUS-210.
Thanks!
The problem is exactly the same as described here:
Exception java.util.zip.ZipFile.ensureOpenOrZipException with WAS 7
Following the resolution, I changed my application module to 2.4 and it resolved the issue. I did not changed the path of wsdl as mentioned in the resolution. But once the application module is changed, the webservices.xml file is not getting generated. I need the xml file to be generated.
Anyone having any alternative solution to this problem where I do not need to change the application module?
Regards,
The original question you are referring to has two parts. One is about the ZIPException. Since that exception is triggered deep down in the WebSphere code it is unlikely that you will get a solution for that problem here. You should contact IBM support for that. The other part is about memory issues. From my experience with using JAX-WS services deployed on WebSphere (and using WebSphere in general), I can make two recommendations:
The original question says that the problem occurs "after few deployments". This poins to a class loader leak. A class loader leak is a particular kind of memory leak that prevents the old class loader of an application from being garbage collected after a redeployment or restart of the application (for a more detailed description, see here). This can be caused by the application or the server runtime. Experience shows that WebSphere itself has several issues that cause this type of leaks, and IBM is in general not very efficient in solving these issues. I once compiled a list of known WebSphere issues of this type that I have encountered. It is published here. One can see that basically any more or less complex Java EE application will be affected by this type of issue. Therefore you should be prepared for the fact that when redeploying frequently without restarting the server, it will eventually run out of memory.
Note: In defense of IBM it should be said that other application servers don't necessarily perform better in this area.
There is one particular case where JAX-WS services deployed on WebSphere may consume unexpectedly large amounts of memory. This occurs for services that have been developed using the top-down approach (i.e. starting from the WSDL), but that have #WebService annotations that don't refer to the original WSDL. In that case, WebSphere (quite correctly) believes that they are bottom-up services and generates WSDL and XML Schema documents based on the JAX-WS/JAXB2 annotations. These documents are kept in memory and in some cases (especially for complex services) may be significantly larger than the original WSDL and XML Schema documents. I've once seen an application that was consuming 200MB of heap just for that. To avoid this, make sure that when creating top-down JAX-WS services, you package the original WSDL and XML Schema documents in the application and that the service implementations have #WebService annotations that correctly refer to these documents.
I wrote an unit-test for an activity which finally puts a message into a queue. As soon as a message is put into that queue, a message driven bean starts processing. But I don't want to test MDBs in a unit test. How can I tell OpenEJB to ignore them?
I set up OpenEJB with several properties:
p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.LocalInitialContextFactory");
p.setProperty("openejb.deployments.classpath.include", ".*");
p.setProperty("openejb.localcopy", "false");
// Messaging
p.put("MyJmsResourceAdapter",
"new://Resource?type=ActiveMQResourceAdapter");
// Do not start the ActiveMQ broker
p.put("MyJmsResourceAdapter.BrokerXmlConfig", "");
p.put("MyJmsConnectionFactory",
"new://Resource?type=javax.jms.ConnectionFactory");
p.put("MyJmsConnectionFactory.ResourceAdapter", "MyJmsResourceAdapter");
p.put("queue/MyQueue",
"new://Resource?type=javax.jms.Queue");
I know I must set openejb.deployments.classpath.exclude, but I can't figure out the right value:
p.setProperty("openejb.deployments.classpath.exclude", "org.example.mdb.*");
For example my class is named org.example.mdb.MyMDB.
just my 2 cents:
try ".*org/example/mdb.*" or ".*org.example.mdb.*"
from Loading Deployments from the Classpath:
Note by default these settings will
only affect which jars OpenEJB will
scan for annotated components when no
descriptor is found. If you would like
to use these settings to also filter
out jars that do contain descriptors,
set the
openejb.deployments.classpath.filter.descriptors
property to true. The default is false
We don't have that feature, but it could easily be added if you wanted to do a little hacking -- new contributions and contributors are always welcome.
This class will do exactly what you want... and a few things you probably don't want :) It strips out all MDBs and JMS resource references (the good part) and it strips out all entity beans and persistence unit references (the part you probably don't want). We wrote it due to some debugging issues we were having when either ActiveMQ or OpenJPA were loaded. If you cleaned it up we'd happily take it back and support it as a feature.
There is a similar feature which strips out all web services. It is installed in the ConfigurationFactory if a specific system property is set. Should be easy to plug an "MDB & JMS" remover using a similar flag at basically that same place in ConfigurationFactory
In fact since in OpenEJB all annotation and xml meta-data is merged into one object tree (which is also a JAXB tree), you could do pretty powerful transformations of the app prior to it being actually deployed. Say for example swap out specific beans for mock versions.
One of those things I think would make an excellent feature but haven't yet had the time to work on. I.e. making some clean hook for people to mess with the tree just before we send it off for deployment. Anyone reading this is welcome to jump in and take a stab at it (yay open source!).