[Installation, Configuration & DEPLOYMENT] - Re: Large web service request, connection prematurely closed
by tinny4u
| <Connector port="8080" address="${jboss.bind.address}"
| maxThreads="250" maxHttpHeaderSize="16384"
| emptySessionPath="true" protocol="HTTP/1.1"
| enableLookups="false" redirectPort="8443" acceptCount="100"
| maxPostSize="10240"
| bufferSize="10240"
| socketBuffer="10240"
| connectionTimeout="240000" disableUploadTimeout="true" />
|
| <!-- Define a SSL HTTP/1.1 Connector on port 8443
| This connector uses the JSSE configuration, when using APR, the
| connector should be using the OpenSSL style configuration
| described in the APR documentation -->
|
| <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
| maxThreads="150" scheme="https" secure="true"
| clientAuth="false" sslProtocol="TLS"
| connectionTimeout="240000"
| maxPostSize="10240"
| bufferSize="10240"
| socketBuffer="10240"
| maxSavePostSize="10240"
| maxHttpHeaderSize="16384"
| disableUploadTimeout="true"
| keystoreFile="${jboss.server.home.dir}/conf/.keystore"
| keystorePass="fact0ring" />
|
|
| <!-- Define an AJP 1.3 Connector on port 8009 -->
| <Connector port="8009" address="${jboss.bind.address}" protocol="AJP/1.3"
| emptySessionPath="true" enableLookups="false" redirectPort="8443" />
|
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223133#4223133
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223133
17 years
[Installation, Configuration & DEPLOYMENT] - Re: Large web service request, connection prematurely closed
by tinny4u
Opps, here the real file.....
<!--APR library loader. Documentation at /docs/apr.html -->
<!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
<!-- Use a custom version of StandardService that allows the
connectors to be started independent of the normal lifecycle
start to allow web apps to be deployed before starting the
connectors.
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<!-- The JAAS based authentication and authorization realm implementation
that is compatible with the jboss 3.2.x realm implementation.
- certificatePrincipal : the class name of the
org.jboss.security.auth.certs.CertificatePrincipal impl
used for mapping X509[] cert chains to a Princpal.
- allRolesMode : how to handle an auth-constraint with a role-name=*,
one of strict, authOnly, strictAuthOnly
+ strict = Use the strict servlet spec interpretation which requires
that the user have one of the web-app/security-role/role-name
+ authOnly = Allow any authenticated user
+ strictAuthOnly = Allow any authenticated user only if there are no
web-app/security-roles
-->
<!-- A subclass of JBossSecurityMgrRealm that uses the authentication
behavior of JBossSecurityMgrRealm, but overrides the authorization
checks to use JACC permissions with the current java.security.Policy
to determine authorized access.
- allRolesMode : how to handle an auth-constraint with a role-name=*,
one of strict, authOnly, strictAuthOnly
+ strict = Use the strict servlet spec interpretation which requires
that the user have one of the web-app/security-role/role-name
+ authOnly = Allow any authenticated user
+ strictAuthOnly = Allow any authenticated user only if there are no
web-app/security-roles
-->
<!-- Uncomment to enable request dumper. This Valve "logs interesting
contents from the specified Request (before processing) and the
corresponding Response (after processing). It is especially useful
in debugging problems related to headers and cookies."
-->
<!--
-->
<!-- Access logger -->
<!--
-->
<!-- Uncomment to enable single sign-on across web apps
deployed to this host. Does not provide SSO across a cluster.
If this valve is used, do not use the JBoss ClusteredSingleSignOn
valve shown below.
A new configuration attribute is available beginning with
release 4.0.4:
cookieDomain configures the domain to which the SSO cookie
will be scoped (i.e. the set of hosts to
which the cookie will be presented). By default
the cookie is scoped to "/", meaning the host
that presented it. Set cookieDomain to a
wider domain (e.g. "xyz.com") to allow an SSO
to span more than one hostname.
-->
<!--
-->
<!-- Uncomment to enable single sign-on across web apps
deployed to this host AND to all other hosts in the cluster.
If this valve is used, do not use the standard Tomcat SingleSignOn
valve shown above.
Valve uses a JBossCache instance to support SSO credential
caching and replication across the cluster. The JBossCache
instance must be configured separately. By default, the valve
shares a JBossCache with the service that supports HttpSession
replication. See the "jboss-web-cluster-service.xml" file in the
server/all/deploy directory for cache configuration details.
Besides the attributes supported by the standard Tomcat
SingleSignOn valve (see the Tomcat docs), this version also
supports the following attributes:
cookieDomain see above
treeCacheName JMX ObjectName of the JBossCache MBean used to
support credential caching and replication across
the cluster. If not set, the default value is
"jboss.cache:service=TomcatClusteringCache", the
standard ObjectName of the JBossCache MBean used
to support session replication.
-->
<!--
-->
<!-- 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
-->
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223131#4223131
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223131
17 years
[Installation, Configuration & DEPLOYMENT] - Re: Large web service request, connection prematurely closed
by tinny4u
Thanks so much for that useful post. Unfortunately none of the configuration changes I made helped.
Here is my server.xml file. As you can see ive tried to get things going in a sort of brute force manner. Am I missing something? Thanks
<!--APR library loader. Documentation at /docs/apr.html -->
<!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
<!-- Use a custom version of StandardService that allows the
connectors to be started independent of the normal lifecycle
start to allow web apps to be deployed before starting the
connectors.
-->
<!-- A "Connector" represents an endpoint by which requests are received
and responses are returned. Documentation at :
Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
Java AJP Connector: /docs/config/ajp.html
APR (HTTP/AJP) Connector: /docs/apr.html
Define a non-SSL HTTP/1.1 Connector on port 8080
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!-- Define an AJP 1.3 Connector on port 8009 -->
<!-- The JAAS based authentication and authorization realm implementation
that is compatible with the jboss 3.2.x realm implementation.
- certificatePrincipal : the class name of the
org.jboss.security.auth.certs.CertificatePrincipal impl
used for mapping X509[] cert chains to a Princpal.
- allRolesMode : how to handle an auth-constraint with a role-name=*,
one of strict, authOnly, strictAuthOnly
+ strict = Use the strict servlet spec interpretation which requires
that the user have one of the web-app/security-role/role-name
+ authOnly = Allow any authenticated user
+ strictAuthOnly = Allow any authenticated user only if there are no
web-app/security-roles
-->
<!-- A subclass of JBossSecurityMgrRealm that uses the authentication
behavior of JBossSecurityMgrRealm, but overrides the authorization
checks to use JACC permissions with the current java.security.Policy
to determine authorized access.
- allRolesMode : how to handle an auth-constraint with a role-name=*,
one of strict, authOnly, strictAuthOnly
+ strict = Use the strict servlet spec interpretation which requires
that the user have one of the web-app/security-role/role-name
+ authOnly = Allow any authenticated user
+ strictAuthOnly = Allow any authenticated user only if there are no
web-app/security-roles
-->
<!-- Uncomment to enable request dumper. This Valve "logs interesting
contents from the specified Request (before processing) and the
corresponding Response (after processing). It is especially useful
in debugging problems related to headers and cookies."
-->
<!--
-->
<!-- Access logger -->
<!--
-->
<!-- Uncomment to enable single sign-on across web apps
deployed to this host. Does not provide SSO across a cluster.
If this valve is used, do not use the JBoss ClusteredSingleSignOn
valve shown below.
A new configuration attribute is available beginning with
release 4.0.4:
cookieDomain configures the domain to which the SSO cookie
will be scoped (i.e. the set of hosts to
which the cookie will be presented). By default
the cookie is scoped to "/", meaning the host
that presented it. Set cookieDomain to a
wider domain (e.g. "xyz.com") to allow an SSO
to span more than one hostname.
-->
<!--
-->
<!-- Uncomment to enable single sign-on across web apps
deployed to this host AND to all other hosts in the cluster.
If this valve is used, do not use the standard Tomcat SingleSignOn
valve shown above.
Valve uses a JBossCache instance to support SSO credential
caching and replication across the cluster. The JBossCache
instance must be configured separately. By default, the valve
shares a JBossCache with the service that supports HttpSession
replication. See the "jboss-web-cluster-service.xml" file in the
server/all/deploy directory for cache configuration details.
Besides the attributes supported by the standard Tomcat
SingleSignOn valve (see the Tomcat docs), this version also
supports the following attributes:
cookieDomain see above
treeCacheName JMX ObjectName of the JBossCache MBean used to
support credential caching and replication across
the cluster. If not set, the default value is
"jboss.cache:service=TomcatClusteringCache", the
standard ObjectName of the JBossCache MBean used
to support session replication.
-->
<!--
-->
<!-- 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
-->
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223130#4223130
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223130
17 years
[Beginners Corner] - EJB timer issue durning server restart
by devireddy
Hi,
I am using JBOSS 4.2.3 AS. The problem I am facing is, I have an EJB timer set to run at 6 am every day. The timer is created using create method of EJB which accepts a start date and time-out period. Which are set to 6 Am next day and 24 hrs respectively while creation.
It runs fine normally, but if for some reason server is restarted or the applications EAR fiel is redeployed(hot deploy) say at 11 AM some day then the timer goes off right away and then the code starts running at 11AM there after instead of 6AM. Probably the server after it starts up, reads the start time in ejb timer (which obviously would be a time in the past as timer was started few days back when it was first created) and times out right away.
To solve this I have provided functionality righ in the application's UI to cancle all and recreate all timers. while recreating timers I set the start time to a future date but the same hour of the day (6 AM next day). My assumption is every time some one changes code or performs a server restart they have to cancel all timers first, do their work and then click on 'create all'.
I am not sure if I am doing it in an efficient way. I want to know if there is a way I can do this using some thing already built in JBOSS. Am I re-inventing the wheel?
Thank you for your time...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223129#4223129
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223129
17 years
[Persistence, JBoss/CMP, Hibernate, Database] - jboss 5 + jtds + xa
by jcg3
Hello--
I am migrating an application from JBoss App Server 4.2.3 to 5.0.1 and have run into a problem with my jTDS datasource (for MS SQL Server) when connecting to multiple databases from the same EJB transaction.
I have set up the datasources for xa according to the instructions here:
http://jboss.org/community/docs/DOC-12242
I am using jtds-1.2.2.jar, which is the latest release of the driver.
Note these datasources as well as the EJBs were behaving correctly on JBoss 4.2.3.GA.
Note that the XA datasource works fine for either/both connections when I only open a connection to one datasource (e.g., for beans where I only talk to one database). When I open the second connection, I get the following stack trace:
16:45:15,038 WARN [logging.loggerI18N] [com.arjuna.ats.internal.jta.transaction.arjunacore.xastart] [com.arjuna.ats.internal.jta.transaction.arjunacore.xastart] TransactionImple.enlistResource - xa_start - caught: XAException.XAER_INVAL for < 131075, 28, 27, 4945455110253551014856535810056515158525710053505010050581029945511025355101485653581005651515852571005350501005058494850 >
16:45:15,038 ERROR [STDERR] javax.transaction.xa.XAException: XAER_INVAL: Invalid arguments were given.
16:45:15,039 ERROR [STDERR] at net.sourceforge.jtds.jdbc.XASupport.raiseXAException(XASupport.java:677)
16:45:15,039 ERROR [STDERR] at net.sourceforge.jtds.jdbc.XASupport.xa_start(XASupport.java:198)
16:45:15,039 ERROR [STDERR] at net.sourceforge.jtds.jdbcx.JtdsXAResource.start(JtdsXAResource.java:105)
16:45:15,039 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:213)
16:45:15,039 ERROR [STDERR] at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:889)
This one has me stumped... suggestions? Googling for XAER_INVAL didn't reveal many options...
As a possible alternative route, the jTDS download has a README.XA, it says that "Many J2EE servers provide their own XA emulations that allow the normal [driver] to be used." Does JBoss 5 support XA Emulation?
Thanks for any suggestions,
Jason
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4223120#4223120
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4223120
17 years