[JBoss JIRA] Created: (JBAS-7447) PersistentManager for sessions is broken
by Emilio Davis (JIRA)
PersistentManager for sessions is broken
----------------------------------------
Key: JBAS-7447
URL: https://jira.jboss.org/jira/browse/JBAS-7447
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.1.0.GA
Reporter: Emilio Davis
Assignee: Remy Maucherat
Using the following context.xml
<Context cookies="true" crossContext="true">
<Manager className="org.apache.catalina.session.PersistentManager" maxIdleSwap="1200" saveOnRestart="true">
<Store checkInterval="60" className="org.apache.catalina.session.JDBCStore" connectionURL="jdbc:mysql://localhost:3306/XXX?user=XXX&password=XXX" driverName="com.mysql.jdbc.Driver" sessionAppCol="app_name" sessionDataCol="session_data" sessionIdCol="session_id" sessionLastAccessedCol="last_access" sessionMaxInactiveCol="max_inactive" sessionTable="tomcat_sessions" sessionValidCol="valid_session"/>
</Manager>
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
</Context>
That used to work in jboss4.0.5GA and correct according to tomcat 6 documentation jboss 5.1.0GA fails to start tomcat with the following exception:
2009-11-02 23:11:54,292 INFO [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deplo
y, ctxPath=/
2009-11-02 23:11:55,619 ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] (main) XML
error parsing: context.xml
org.jboss.xb.binding.JBossXBException: Failed to parse source: Store not found as a child of Manager
in unordered_sequence: attributes?
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:183)
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextCo
nfig.java:573)
at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:536)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeploymen
t.java:310)
at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:1
42)
at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
at $Proxy38.start(Unknown Source)
I opened a thread in the tomcat integration forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=163337) but got no response.
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-8786) JBoss unpacks all jars from WEB-INF\lib of war file
by Maxym Pendyshchuk (JIRA)
JBoss unpacks all jars from WEB-INF\lib of war file
---------------------------------------------------
Key: JBAS-8786
URL: https://issues.jboss.org/browse/JBAS-8786
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Final
Environment: Windows XP x32
Reporter: Maxym Pendyshchuk
while starting JBoss AS it unpacks all jar files, which are located in WEB-INF/lib folder of each my war file. It means that in tmp folder mostly I see folder with jar file, and folder with its content. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files:
asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar
asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar"
actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp:
asm-3.1.jar-215a36131ebb088e/asm-3.1.jar
asm-3.1.jar-14695f157664f00/contents/
but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.
the problem is that it slows down application server booting (when I repack all my war files as ear and moved war libraries to ear/lib folder then I save 2+ minutes at JBoss 6 booting...). If it is done deliberately (so it improves some performance at runtime), then would be nice to have a configuration option, so during development I can save time to boot my local JBoss AS
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months
[JBoss JIRA] Created: (JBRULES-2289) Support JPA Resource Local EntityTransaction based Transactions
by Michael Youngstrom (JIRA)
Support JPA Resource Local EntityTransaction based Transactions
---------------------------------------------------------------
Key: JBRULES-2289
URL: https://jira.jboss.org/jira/browse/JBRULES-2289
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 5.0.1.FINAL
Reporter: Michael Youngstrom
Assignee: Mark Proctor
It would be nice if wherever JPA is used in Drools (drools-flow in particular) there was support for RESOURCE_LOCAL transactions through JPA's EntityTransaction interface as an alternative to JTA.
Support for resource local transactions would reduce the base Drools Flow dependency footprint (no need for bitronix) as well as allow Drools to be used in a containerless or Tomcat like environment without a JTA implementation available. Although embeddable solutions are available they are often either buggy or complex. It would be nice to not have to deal with them if possible.
If the idea is acceptable I'd be willing to put together an initial patch.
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBMESSAGING-1791) ConcurrentModificationException at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally
by Tamas Cserveny (JIRA)
ConcurrentModificationException at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally
-----------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-1791
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1791
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.0.SP3
Environment: JBoss AS 4.2.3.GA Release (JBossESB 4.7)
jboss.messaging.jmsVersion=1.1
jboss.messaging.jmsMajorVersion=1
jboss.messaging.jmsMinorVersion=1
jboss.messaging.jmsProviderName=JBoss Messaging
jboss.messaging.providerVersion=1.4.0.SP3
jboss.messaging.providerMajorVersion=1
jboss.messaging.providerMinorVersion=4
jboss.messaging.providerIncrementingVersion=21
Reporter: Tamas Cserveny
Hi,
I found a CME in the JBoss-messageing.
Test scenario:
Vanilla JBossESB 4.7 with a simple flow. (file -> queue, bridge queue to another queue, queue -> file)
I kept this server running on a 2 core system with a load of 10 messages / sec. (ca 3kb messages).
I received many of these exception during the test. It caused some messages to stuck into the queue, but eventually they were redelivered. (Not after 5s, but after some other messages). They were counted in the 'DeliveringCount', and stayed like that.
Cheers,
Tamas
2010-02-26 00:00:50,083 ERROR [org.jboss.jms.client.container.ClientConsumer] Failed to deliver message
javax.jms.JMSException: There is no transaction with id LocalTx[m0r-676r546g-1-2tbmq36g-nq5p47-51zk6a]
at org.jboss.jms.tx.ResourceManager.addAck(ResourceManager.java:186)
at org.jboss.jms.client.container.SessionAspect.handlePreDeliver(SessionAspect.java:293)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect19.invoke(SessionAspect19.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate$preDeliver_5548846795541436298.invokeNext(ClientSessionDelegate$preDeliver_5548846795541436298.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$preDeliver_5548846795541436298.invokeNext(ClientSessionDelegate$preDeliver_5548846795541436298.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.preDeliver(ClientSessionDelegate.java)
at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientConsumer.java:152)
at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:976)
at org.jboss.messaging.util.JBMExecutor$TCLExecutor.run(JBMExecutor.java:78)
at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
at java.lang.Thread.run(Thread.java:619)
2010-02-26 00:03:22,084 ERROR [org.jboss.messaging.util.ExceptionUtil] ConnectionEndpoint[uip-txvw446g-1-2tbmq36g-nq5p47-51zk6a] sendTransaction [f6r-ghfu546g-1-2tbmq36g-nq5p47-5
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally(ServerSessionEndpoint.java:1474)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.java:810)
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:473)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:195)
--
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
14 years, 11 months
[JBoss JIRA] Created: (JGRP-619) Change getState semantics
by Vladimir Blagojevic (JIRA)
Change getState semantics
-------------------------
Key: JGRP-619
URL: http://jira.jboss.com/jira/browse/JGRP-619
Project: JGroups
Issue Type: Task
Affects Versions: 2.5, 2.4, 2.3, 2.2.9
Reporter: Vladimir Blagojevic
Assigned To: Vladimir Blagojevic
Fix For: 3.0
Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer.
We have to simplify this process! State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener.
This issue is closely related to revamping of channel state transfer callbacks - JGRP-563
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-8797) Logging with SLF4J produces wrong output when using multiple parameters in format
by Jens Reimann (JIRA)
Logging with SLF4J produces wrong output when using multiple parameters in format
---------------------------------------------------------------------------------
Key: JBAS-8797
URL: https://issues.jboss.org/browse/JBAS-8797
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.Final
Environment: Ubuntu Linux 64bit
Reporter: Jens Reimann
Assignee: David Lloyd
Logging with SLF4J and passing parameters as Object[] produces wrong output in the JBoss log:
e.g.: logger.debug ( "Logging - Level: {}, Action: {}, Result: {}, UserData: {}, Reference: {}/{}", new Object[] { level, action, result, data, referenceType, referenceId } );
produces
Logging - Level: <parameter #1 as Object[]>, Action: {}, Result: {}, ....
It seems to me that instead of handling the Object[] that is passed as array is used later on as simple Object which reduces the provided parameters to 1 instead. There seems to be no problem with the log calls that take one or two objects (which are separate methods in SLF4J).
I would consider it major since it scrambles all logging messages using the Object[] methods.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 11 months