February 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBAS-3007) session timeout not implimented properly

by vikas mishra (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3007?page=comments#action_12399190 ] vikas mishra commented on JBAS-3007: ------------------------------------ I had same problem with jboss-4.0.4.CR2. It never invalidate the session even after days.but same aplication working fine with tomcat 5.5.X. if i user a sample war with only use of session.setMaxInactiveInterval() for timeout then it work properly. but the case like us where complexity is more(bcoz we uses own Httpsession[child class of HttpSession] class) then it never invalidate session. so I replaced the catalina.jar of jboss_home\server\default\deploy\jbossweb-tomcat55.sar with tomcat's and my problem is gone away. > session timeout not implimented properly > ---------------------------------------- > > Key: JBAS-3007 > URL: http://jira.jboss.com/jira/browse/JBAS-3007 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Windows XP Professional Service Pack 2 > Reporter: Prashant Tejura > Assigned To: Remy Maucherat > Fix For: JBossAS-5.0.0.Beta1, JBossAS-4.0.4.GA > > > HttpSession lives well beyond the specified time in {myWebApp}WEB/web.xml <session-timeout>1</session-timeout> . I also tried to programatically override it using session.setMaxInactiveInterval(60); but it is still alive for more than 60 secs. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-690) Thread interrupt status is not always cleared by default

by Vladimir Blagojevic (JIRA)

Thread interrupt status is not always cleared by default -------------------------------------------------------- Key: JGRP-690 URL: http://jira.jboss.com/jira/browse/JGRP-690 Project: JGroups Issue Type: Bug Affects Versions: 2.6, 2.7 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6.2, 2.7 If Thread#interrupt() is invoked on a thread that is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException. (citing Thread#interrupt javadoc) Conventional wisdom was that interrupt signal was always cleared. However, in cases except the above interrupt signal is actually not cleared! JGroups code that is throwing InterruptedException should make sure that it also clears the interrupt status. Otherwise, if we wrongly assume that interrupt status is always cleared, we can have inconsistencies that can lead to hard-to-trace bugs (See below). We should verify that throughout our code that we always clear interrupt status. Gray said on javagroups-list: We have been seeing a large percentage of our production servers (on 2.6.1) spinning above 100% of CPU. After some investigation, we seem to have found an infinite loop in Scheduler.java. If sched_thread gets interrupted, its interrupt flag never gets reset so it spins forever suspending and resuming the current_thread and throwing and catching InterruptedException(s). According to jconsole, one of our boxes has done this 690 million times -- nice effort. When this is happening, the memory space is alternating between 200 and 300 mb which makes sense given the exception bandwidth. We are running our RPC dispatchers wth deadlock_detection and concurrent_processing set to true and use_concurrent_stack="true". Here are http://www.nabble.com/file/p15395455/stack_dumps.txt some stack snapshots of the spinning thread . As you can see they are all in Scheduler.run. Here is the section from http://www.nabble.com/file/p15395455/Scheduler.java.txt Scheduler.java with the offending part of the code including where sched_thread is being interrupted by a call to Scheduler.addPrio(). The pluses show where we think a missing Thread.interrupt() call should be. Here's the http://www.nabble.com/file/p15395455/Scheduler.java.patch.txt patch for Scheduler.java (from 2.6.1) which adds in the interrupt call. This is all with Jgroups 2.6.1. Anyone else see this behavior? We're going to roll this patch out to see if it stops the spinning. gray -- 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

18 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-661) Security: Deploying a bean without mandatory org.jboss.ejb3.security.SecurityDomain results in a NullPointerException

by Galder Zamarreno (JIRA)

Security: Deploying a bean without mandatory org.jboss.ejb3.security.SecurityDomain results in a NullPointerException --------------------------------------------------------------------------------------------------------------------- Key: EJBTHREE-661 URL: http://jira.jboss.com/jira/browse/EJBTHREE-661 Project: EJB 3.0 Issue Type: Bug Components: Security Affects Versions: EJB 3.0 RC7 - FD Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Fix For: EJB 3.0 RC9 - FD When setting up security in a EJB3 bean, it is mandatory adding the org.jboss.ejb3.security.SecurityDomain tag. Failure to do so results on a NullPointerException. AS should log a more meaningful message rather than a NullPointerException. -- 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

18 years, 5 months

6
11
0 / 0

[JBoss JIRA] Created: (JBSER-97) RegularObjectPersister.readSlotWithFields to log number of fields being read

by Galder Zamarreno (JIRA)

RegularObjectPersister.readSlotWithFields to log number of fields being read ---------------------------------------------------------------------------- Key: JBSER-97 URL: http://jira.jboss.com/jira/browse/JBSER-97 Project: JBoss Serialization Issue Type: Task Affects Versions: 1.0.3 GA Reporter: Galder Zamarreno Assigned To: Clebert Suconic Priority: Minor writeSlotWithFields logs the slot name and number of fields to be written. for debugging pupouses, readSlotWithFields could do with logging the number of fields written too, i.e. RegularObjectPersister.readSlotWithFields() to start like this: short numberOfFields = (short)fieldsKey.length; if (isDebug) { log.debug("readSlotWithFields slot=" + slot.getSlotClass().getName() + " and " + numberOfFields + " fields"); } instead of: if (isDebug) { log.debug("readSlotWithFields slot=" + slot.getSlotClass().getName()); } //final int numberOfFields = input.readShort(); short numberOfFields = (short)fieldsKey.length; -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5161) Preferred master API should live on its own hasingleton election policy

by Galder Zamarreno (JIRA)

Preferred master API should live on its own hasingleton election policy ----------------------------------------------------------------------- Key: JBAS-5161 URL: http://jira.jboss.com/jira/browse/JBAS-5161 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Fix For: JBossAS-5.0.0.Beta4 HASingletonElectionPolicy should only contain methods that actually called from the HASingletonSupport/HASingletonController classes so that they can inject attributes to the election policy that users don't have to specify in the ha singleton election policy bean definition.Therefore: /** * Sets the preferred master node. As long as the preferred master node * presents in the cluster, it will be always selected as master node, * no matter what the election policy is. * @param node String format of ip_address:port_number */ void setPreferredMaster(String node); String getPreferredMaster(); The methods above should not live in HASingletonElectionPolicy, but instead on its own policy impl class.. -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBBUILD-451) Add rmi compilation for server and iiop modules.

by Paul Gier (JIRA)

Add rmi compilation for server and iiop modules. ------------------------------------------------ Key: JBBUILD-451 URL: http://jira.jboss.com/jira/browse/JBBUILD-451 Project: JBoss Build System Issue Type: Feature Request Components: Maven Reporter: Paul Gier Assigned To: Paul Gier Fix For: Maven Build - App Server The server and iiop modules need to use the rmic plugin to generate rmi stubs and other files. -- 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

18 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5228) Race condition maintaining acknowledgements when pushing messages to the client

by Adrian Brock (JIRA)

Race condition maintaining acknowledgements when pushing messages to the client ------------------------------------------------------------------------------- Key: JBAS-5228 URL: http://jira.jboss.com/jira/browse/JBAS-5228 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA There is a race condition when maintaining/checking message acknowledgements for a subscription when messages are pushed to the client. i.e. when the client asks for a message and there are none, the client is registered as wanting a message and when a message arrives, the message is sent to the client. This involves maintaining a "list" of unacknowledged messages for that client/subscription which must be checked before we allow removal of the the subscription during close. However, for pushing the maintanance of the unacknowledged messages can race with the close of the subscription because they are not maintained in the same synchronized block as deciding the client wants the message. BasicQueue::internalAddMessage() try { Subscription found = null; // In this synchronized block we decide that a client wants the message synchronized (receivers) { if (receivers.size() != 0) { for (Iterator it = receivers.iterator(); it.hasNext();) { Subscription sub = (Subscription) it.next(); if (sub.accepts(message.getHeaders())) { it.remove(); found = sub; break; } } } ... But only later outside this block do we maintain the unacknowledged messages // Queue to the receiver if (found != null) queueMessageForSending(found, message); This means that during the ... above a close of the subscription which leads to an invocation of hasUnackedMessages() could decide there are no unacknoweldged messages. -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5088) Failing org.jboss.test.jbossmq.test.ConnectionConsumerErrorFiredUnitTestCase.testExceptionListenerFiredOnError (jrockit)

by Dimitris Andreadis (JIRA)

Failing org.jboss.test.jbossmq.test.ConnectionConsumerErrorFiredUnitTestCase.testExceptionListenerFiredOnError (jrockit) ------------------------------------------------------------------------------------------------------------------------ Key: JBAS-5088 URL: http://jira.jboss.com/jira/browse/JBAS-5088 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JMS service Reporter: Dimitris Andreadis Assigned To: Adrian Brock Fix For: JBossAS-4.2.3.GA Without any changes reported here: http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-4.2.x-Test... The following test has been failing for the last 5 builds, in the jrockit run only: http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-4.2.x-Test... junit.framework.AssertionFailedError: ExceptionListener should have been invoked at org.jboss.test.jbossmq.test.ConnectionConsumerErrorFiredUnitTestCase.testExceptionListenerFiredOnError(ConnectionConsumerErrorFiredUnitTestCase.java:59) -- 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

18 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBXB-119) AttributeBinding shouldn't be created with complex type w/o ValueAdapter

by Alexey Loubyansky (JIRA)

AttributeBinding shouldn't be created with complex type w/o ValueAdapter ------------------------------------------------------------------------ Key: JBXB-119 URL: http://jira.jboss.com/jira/browse/JBXB-119 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR5 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossXB-2.0.0.CR6 Currently it can be created but at runtime exceptions such as NPE will be thrown. -- 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

18 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-5227) Multiple remote invoker bindings for ClientUserTransaction

by Galder Zamarreno (JIRA)

Multiple remote invoker bindings for ClientUserTransaction ---------------------------------------------------------- Key: JBAS-5227 URL: http://jira.jboss.com/jira/browse/JBAS-5227 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transaction Manager Affects Versions: JBossAS-4.2.2.GA Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Remote EJB users might want to enable different invoker bindings for their EJBs so that they can be accessed via different invokers. However currently, UserTransaction can only be bound with one invoker at the time. This feature request is to enable binding UserTransaction with multiple invokers so that remote clients can locate the UserTransaction that best suits their invoker requirements. Notes: ClientUserTransactionService currently binds to java:/UserTransaction and this is not configurable (comes from a static variable). There's another binding as well related to the UserTransaction factory, whose lookup is currently hardcoded as it's expected there's only ClientUserTransactionService with a single proxy/transport type. -- 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

18 years, 5 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2008