I try to increase ejb transaction timeout in WildFly.
There are 3 options to do it:
via standalone-full.xml file, affects all components globally
via #org.jboss.ejb3.annotation.TransactionTimeout wildfly specific annotation. Requires code changes.
via jboss-ejb3.xml file.
The last option does not work with Wilfly 10. The example could be taken from Specification of Transaction Timeout in the Deployment Descriptor
The problem is that the documentation belongs to version 9. Beginning from WF 10, I do not see this timeout-specific section in Wilfly 10 jboss-ejb3.xml Reference
Also existing examples refers to transaction xsd schema, but it does not exist anymore, see jboss xsd existing schemas.
In the github repo it could be found: github transaction xsd schema
Does this ability to control transaction with the option #3 still exists? Or what do I miss with it?
Related
The last few days I take a look to use infinispan to manage a cache with my applications. I have some ears applications that runs on same wildfly and
my purpose is to have a local cache that all my application can use. This cache will not be shared between the nodes.
My intention was to use infinspan with jcache, so in this manner I can annotate my functions to cache the result.
I'm not interested in a replicated cache, because the data that I'm going to cache will be evicted every 5 minutes and the data will not be duplicated on the nodes
(the session of the client is persisted and the clients call these function with differente key value a lot of times).
I'm using wildlfy 14 with the standalone-full profile and I took some look into the documentation online.
I added a new cache container to the configuration system, also via the cli
/subsystem=infinispan/cache-container=container-name:add
/subsystem=infinispan/cache-container=container-name/local-cache=container-name-default:add
/subsystem=infinispan/cache-container=container-name/local-cache=container-name-sd:add
I see that the container and the cache are not published with jndi and using the wildfly console I can't find the added caches in the jndi runtime string.
Without the jndi string, I can't access to the cache.
Becasue at first moment my intenction was to use JCache, I found the documentation on infinispan website to add the complete module of infinispan to wildlfy.
To use the module donwloaded, I extended wildfly with the infinispan module in extensions tag section.
Using the standalone full profile, I had some errors with the access to the cache and the #CacheResult annotation wasn't fired, also with the beans.xml defined with the interceptors
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" version="1.1" bean-discovery-mode="all">
<interceptors>
<class>org.infinispan.jcache.annotation.InjectedCacheResultInterceptor</class>
<class>org.infinispan.jcache.annotation.InjectedCachePutInterceptor</class>
<class>org.infinispan.jcache.annotation.InjectedCacheRemoveEntryInterceptor</class>
<class>org.infinispan.jcache.annotation.InjectedCacheRemoveAllInterceptor</class>
</interceptors>
At the end I found that using standalone ha wildfy profile and adding a jgroup to the cache container, I'm able to publish the cache with a jndi string and use it.
Is there a simple method to create and access a local cache with infinispan and wildfly 14? Do someone can provide an example with an ear application?
Is it correct that I need to use the ha profile to define new cache container with jgroups? I found that in the full wildfly profile, the infinispan cache is usde only for internal use, so it is necessary to use the ha profile as I said before.
Thanks for every answer and I hope I was enough clear.
I'm trying to add session clustering in jetty and haven't been succcessfull. tried different article and solutions. Below are my trials. Any help is greatly appreciated
Trial 1
Adding --module=jdbc-sessions in start.ini didn't work. Say a warning that jdbc-sessions is not a valid module
java -jar ../start.jar
WARNING: Cannot enable requested module [jdbc-sessions]: not a valid module name.
Trial 2
Tried adding --add-to-startd while starting jetty. It didn't add jdbc-sessions to start.ini file.
Jetty version:jetty-distribution-9.2.15
JDBC Sessions were not managed by the Jetty Module system until Jetty 9.3. Documentation for how to implement JDBC Sessions in Jetty 9.2 can be found here. If you wanted to you could create your own JDBC module using the templates shown here.
On a side note, I would recommend upgrading your Jetty distribution unless you have a compelling reason to stay with 9.2. Jetty 9.4 has a milestone release out already and a full release is expected in the next month or two.
I'm new to Dropwizard. In the newest documentation, it refers to "Service" as the main entry point of any application. But in the example code, it actually uses "Application". I'm assuming that "Application" is a new name for "Service", since I can't find "Service" in the new source code.
I also noticed that the namespace has changed from "com.yammer" to "com.codehaus" to "io.dropwizard". I'm assuming it reflects the evolution of the project itself. Just out of curiosity, can anyone add some context to how this came about?
Both the naming changes you cited are actually changes for the upcoming Version 0.7. The documentation isn't up-to-date yet (and is actually the main thing holding back the 0.7 release according to the mailing list).
The current release notes can be found in the master branch.
Upgraded to Java 7.
Moved to the io.dropwizard group ID and namespace.
Extracted out a number of reusable libraries: dropwizard-configuration,
dropwizard-jackson, dropwizard-jersey, dropwizard-jetty, dropwizard-lifecycle,
dropwizard-logging, dropwizard-servlets, dropwizard-util, dropwizard-validation.
Extracted out various elements of Environment to separate classes: JerseyEnvironment,
LifecycleEnvironment, etc.
Extracted out dropwizard-views-freemarker and dropwizard-views-mustache.
dropwizard-views just provides infrastructure now.
Renamed Service to Application.
Added dropwizard-forms, which provides support for multipart MIME entities.
Added dropwizard-spdy.
Added AppenderFactory, allowing for arbitrary logging appenders for application and request
logs.
Added ConnectorFactory, allowing for arbitrary Jetty connectors.
Added ServerFactory, with multi- and single-connector implementations.
Added ReporterFactory, for metrics reporters, with Graphite and Ganglia implementations.
Added ConfigurationSourceProvider to allow loading configuration files from sources other than
the filesystem.
Added setuid support. Configure the user/group to run as and soft/hard open file limits in the
ServerFactory. To bind to privileged ports (e.g. 80), enable startAsRoot and set user
and group, then start your application as the root user.
Added builders for managed executors.
Added a default check command, which loads and validates the service configuration.
Added support for the Jetty HTTP client to dropwizard-client.
Added Jackson Afterburner support.
Added support for deflate-encoded requests and responses.
Added support for HTTP Sessions. Add the annotated parameter to your resource method:
#Session HttpSession session to have the session context injected.
Added support for a "flash" message to be propagated across requests. Add the annotated parameter
to your resource method: #Session Flash message to have any existing flash message injected.
Added support for deserializing Java enums with fuzzy matching rules (i.e., whitespace
stripping, -/_ equivalence, case insensitivity, etc.).
Added HibernateBundle#configure(Configuration) for customization of Hibernate configuration.
Added support for Joda Time DateTime arguments and results when using JDBI.
Added configuration option to include Exception stack-traces when logging to syslog. Stack traces
are now excluded by default.
Added the application name and PID (if detectable) to the beginning of syslog messages, as is the
convention.
Added --migrations-file command-line option to migrate command to supply the migrations
file explicitly.
Validation errors are now returned as application/json responses.
Simplified AsyncRequestLog; now standardized on Jetty 9 NCSA format.
Renamed DatabaseConfiguration to DataSourceFactory, and ConfigurationStrategy to
DatabaseConfiguration.
Changed logging to be asynchronous. Messages are now buffered and batched in-memory before being
delivered to the configured appender(s).
Changed handling of runtime configuration errors. Will no longer display an Exception stack-trace
and will present a more useful description of the problem, including suggestions when appropriate.
Changed error handling to depend more heavily on Jersey exception mapping.
Changed dropwizard-db to use tomcat-jdbc instead of tomcat-dbcp.
Changed default formatting when logging nested Exceptions to display the root-cause first.
Replaced ResourceTest with ResourceTestRule, a JUnit TestRule.
Dropped Scala support.
Dropped ManagedSessionFactory.
Dropped ObjectMapperFactory; use ObjectMapper instead.
Dropped Validator; use javax.validation.Validator instead.
Fixed a shutdown bug in dropwizard-migrations.
Fixed formatting of "Caused by" lines not being prefixed when logging nested Exceptions.
Fixed not all available Jersey endpoints were being logged at startup.
Upgraded to argparse4j 0.4.1.
Upgraded to Guava 15.
Upgraded to Hibernate Validator 5.0.1.
Upgraded to Jackson 2.2.3.
Upgraded to JDBI 2.50.
Upgraded to Jetty 9.0.5.
Upgraded to Liquibase 3.0.4.
Upgraded to Logback 1.0.13.
Upgraded to Metrics 3.0.1.
Upgraded to Mustache 0.8.13.
Upgraded to SLF4J 1.7.5.
I am trying some performance tuning and following Jboss performance tuning guide. so i read chapter 3, and i want to turn of Cached Connection Manager. but there is mentioned its configuration is in server.xml. I can't find server.xml anywhere. I am using jboss-eap-6.1 on windows 7. So my question where i will find server.xml or how can i turn off Cached Connection Manager ??
here is the text from tunning guide :
The configuration is in the file server.xml in the directory JBOSS_EAP_DIST/jboss-as/server//deploy/jbossweb.sar. Note that the minimal configuration does not include JBoss Web.
Below is an extract from server.xml in which the CachedConnectionManager is enabled.
<!-- Check for unclosed connections and transaction terminated checks in servlets/jsps. Important: The dependency on the CachedConnectionManager in META-INF/jboss-service.xml must be uncommented, too -->
<Valve className="org.jboss.web.tomcat.service.jca.CachedConnectionValve" cachedConnectionManagerObjectName="jboss.jca:service=CachedConnectionManager" transactionManagerObjectName="jboss:service=TransactionManager" />
To disable the CachedConnectionManager, comment the last three lines, as per the following example:
<!-- Check for unclosed connections and transaction terminated checks in servlets/jsps. Important: The dependency on the CachedConnectionManager in META-INF/jboss-service.xml must be uncommented, too
<Valve className="org.jboss.web.tomcat.service.jca.CachedConnectionValve" cachedConnectionManagerObjectName="jboss.jca:service=CachedConnectionManager" transactionManagerObjectName="jboss:service=TransactionManager" /> -->
Another configuration file also needs to be edited: jboss-beans.xml in the JBOSS_EAP_DIST/jboss-as/server//deploy/jbossweb.sar/META-INF directory. Note that the minimal configuration does not include JBoss Web. This file is used by the micro-container for JBoss Web’s integration with it, and it specifies the connections between the dependent components. In this case, the CachedConnectionManager’s valve is dependent on the transaction manager. So, in order to get rid of the valve properly, we have to remove the dependency information from this configuration file. The pertinent information is at the top of the file, and it looks like the following:
<!-- Only needed if the org.jboss.web.tomcat.service.jca.CachedConnectionValve is enabled in the tomcat server.xml file. -?
<depends>jboss.jca:service=CachedConnectionManager</depends>
<!-- Transaction manager for unfinished transaction checking in the CachedConnectionValve -->
<depends>jboss:service=TransactionManager</depends>
Comment these lines as in the following example:
jboss.jca:service=CachedConnectionManager -?
jboss:service=TransactionManager</depends>-->
The version of EAP you are using has a different file structure from what your configuration guide is telling you. Are you using a configuration guide for JBoss AS 6 to configure JBoss EAP 6? If so, this is the source of your frustration.
The instructions you have are for what looks like an EAP 5 file structure.
You can find EAP 6 documentation here.
If you are running in standalone mode, your config will be found at ${JBOSS_HOME}/standalone/configuration/standalone.xml
I am having troubles migrating from OC4J 10.1.2.3 to 10.1.3.1.4. The problem is for applications that have multiple EJBs (all are 2.1, no EJB 3.0). Jdeveloper will take the default ejb-jar.xml (the one required for Jdeveloper to run it on its stand-alone OC4J instance) and package it into each EJB JAR module NO MATTER what. This results in the app server drilling into each EJB JAR module when deploying, and find the same ejb-jar.xml file N times (where N = number of EJB Modules). This results in duplicate EJB references and will break any JNDI lookups such as: "java:comp/env/ejb/EJBName". Thus deploying an app that has 3 EJBs, EJB1, EJB2 and EJB3 causes the app server to register 9 EJBs instead of 3. I need a best practices way, but in between the way 10.1.3.4 and JDeveloper are acting the situation is rather dire...
Side note: They will work if the web app's JNDI look-up code is refractored to just "ejb/EJBName". This is not desirable though.
You should check the Oracle documentation to see which is your case.
The Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide is a good start
According to the Oracle® Containers for J2EE Services Guide, chapter 2: Using JNDI
when you use the form "ejb/EJBName" you perform "local" lookup. If you want to use the full form you must check the "Enabling Global JNDI Lookups" section of the "Using JNDI" chapter.
The problem was multiple reference in our deployment profiles. We were create a deployment profile for EACH EJB. This meant that each EJB had it's own ejb-jar.xml (this file contained a description of all EJBS in the project). Therefore, every time JDeveloper created an EJB, it placed a descriptor of all EJBS in each EJB it generated, causing an NxN amount of references. Therefore Nx(N-1) extra references.
Now, the key point is that Oracle Application Server 10.1.2.3.0 and bellow did not care about these duplicate references. However as we can see, 10.1.3.1.4 is a much different version and this did break.
Our fix: to have only 1 EJB Deployment profile that contains all of the EJB classes and the POJO's that they use. Remember, before there was 1 EJB Profile for each EJB... All this did was allow for Jdeveloper (which is crap IMHO) to correctly generate a valid EAR. A combination of Jdeveloper and Oracle's Application Server's crap is what caused this.