November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8635) MailResourceAdapter mail check triggered only once

by Martin Clauss (JIRA)

MailResourceAdapter mail check triggered only once -------------------------------------------------- Key: JBAS-8635 URL: https://jira.jboss.org/browse/JBAS-8635 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: 6.0.0.M5 Environment: Win7, JBoss 6.0.0.M5, Java 1.6.0_21 Ubuntu lucid, JBoss 6.0.0.M5, Java 1.6.0_18 Reporter: Martin Clauss Assignee: Jesper Pedersen Mail check is performed correctly only once (after first timeout of pollingInterval) and then never again... 18:43:13,690 INFO [org.jboss.ejb3.deployers.JBossASKernel] installing bean: jboss.j2ee:ear=CTAEar.ear,jar=CTAEJB3.jar,name=MailBean,service=EJB3 18:43:13,690 INFO [org.jboss.ejb3.deployers.JBossASKernel] with dependencies: 18:43:13,690 INFO [org.jboss.ejb3.deployers.JBossASKernel] and demands: 18:43:13,690 INFO [org.jboss.ejb3.deployers.JBossASKernel] jboss.ejb:service=EJBTimerService; Required: Described 18:43:13,690 INFO [org.jboss.ejb3.deployers.JBossASKernel] and supplies: 18:43:13,690 INFO [org.jboss.ejb3.deployers.JBossASKernel] jndi:null 18:43:13,691 INFO [org.jboss.ejb3.deployers.JBossASKernel] Class:org.jboss.resource.adapter.mail.inflow.MailListener 18:43:13,691 INFO [org.jboss.ejb3.deployers.JBossASKernel] Added bean(jboss.j2ee:ear=CTAEar.ear,jar=CTAEJB3.jar,name=MailBean,service=EJB3) to KernelDeployment of: CTAEJB3.jar 18:43:13,741 INFO [org.jboss.ejb3.EJBContainer] STARTED EJB: com.contactulater.ba.MailBean ejbName: MailBean ****snip**** 18:44:13,749 INFO [STDOUT] DEBUG: JavaMail version 1.4.2 18:44:13,760 INFO [STDOUT] DEBUG: successfully loaded resource: /META-INF/javamail.default.providers 18:44:13,761 INFO [STDOUT] DEBUG: Tables of loaded providers 18:44:13,761 INFO [STDOUT] DEBUG: Providers Listed By Class Name: {com.sun.mail.smtp.SMTPSSLTransport=javax.mail.Provider ***snip*** 18:44:13,763 INFO [STDOUT] DEBUG: successfully loaded resource: /META-INF/javamail.default.address.map 18:44:13,771 INFO [STDOUT] DEBUG: setDebug: JavaMail version 1.4.2 18:44:13,771 INFO [STDOUT] DEBUG: getProvider() returning javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Sun Microsystems, Inc] 18:44:13,772 INFO [STDOUT] DEBUG: mail.imap.fetchsize: 16384 18:44:13,772 INFO [STDOUT] DEBUG: mail.imap.statuscachetimeout: 1000 18:44:13,773 INFO [STDOUT] DEBUG: mail.imap.appendbuffersize: -1 18:44:13,773 INFO [STDOUT] DEBUG: mail.imap.minidletime: 10 18:44:13,774 INFO [STDOUT] DEBUG: trying to connect to host "127.0.0.1", port 143, isSSL false 18:44:13,799 INFO [STDOUT] * OK **** Cyrus IMAP4 v2.2.13-Debian-2.2.13-19 server ready 18:44:13,800 INFO [STDOUT] A0 CAPABILITY 18:44:13,820 INFO [STDOUT] * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS 18:44:13,821 INFO [STDOUT] A0 OK Completed 18:44:13,821 INFO [STDOUT] DEBUG: protocolConnect login, host=127.0.0.1, user=jbossra, password=<non-null> 18:44:13,844 INFO [STDOUT] A1 OK User logged in 18:44:13,845 INFO [STDOUT] A2 CAPABILITY 18:44:13,868 INFO [STDOUT] * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE LOGINDISABLED 18:44:13,869 INFO [STDOUT] A2 OK Completed 18:44:13,870 INFO [STDOUT] A3 LIST "" INBOX 18:44:13,889 INFO [STDOUT] * LIST (\HasChildren) "." "INBOX" 18:44:13,890 INFO [STDOUT] A3 OK Completed (0.000 secs 4 calls) 18:44:13,891 INFO [STDOUT] DEBUG: connection available -- size: 1 18:44:13,891 INFO [STDOUT] A4 SELECT INBOX 18:44:13,973 INFO [STDOUT] * FLAGS (\Answered \Flagged \Draft \Deleted \Seen) 18:44:13,973 INFO [STDOUT] * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] 18:44:13,973 INFO [STDOUT] * 2 EXISTS 18:44:13,974 INFO [STDOUT] * 0 RECENT 18:44:13,974 INFO [STDOUT] * OK [UIDVALIDITY 1288029487] 18:44:13,974 INFO [STDOUT] * OK [UIDNEXT 4] 18:44:13,974 INFO [STDOUT] A4 OK [READ-WRITE] Completed 18:44:13,974 INFO [STDOUT] A5 SEARCH UNSEEN ALL 18:44:13,993 INFO [STDOUT] * SEARCH 18:44:13,993 INFO [STDOUT] A5 OK Completed (0 msgs in 0.000 secs) 18:44:13,993 INFO [STDOUT] A6 CLOSE 18:44:14,138 INFO [STDOUT] A6 OK Completed 18:44:14,138 INFO [STDOUT] DEBUG: added an Authenticated connection -- size: 1 18:44:14,138 INFO [STDOUT] IMAP DEBUG: IMAPProtocol noop 18:44:14,138 INFO [STDOUT] A7 NOOP 18:44:14,156 INFO [STDOUT] A7 OK Completed 18:44:14,156 INFO [STDOUT] A8 LOGOUT 18:44:14,175 INFO [STDOUT] * BYE LOGOUT received 18:44:14,175 INFO [STDOUT] A8 OK Completed 18:44:14,176 INFO [STDOUT] DEBUG: IMAPStore connection dead 18:44:14,176 INFO [STDOUT] DEBUG: IMAPStore cleanup, force false 18:44:14,176 INFO [STDOUT] DEBUG: IMAPStore cleanup done MDB implementation: @MessageDriven(activationConfig={ @ActivationConfigProperty(propertyName="mailServer", propertyValue="127.0.0.1"), @ActivationConfigProperty(propertyName="mailFolder", propertyValue="INBOX"), @ActivationConfigProperty(propertyName="storeProtocol", propertyValue="imap"), @ActivationConfigProperty(propertyName="userName", propertyValue="jbossra"), @ActivationConfigProperty(propertyName="password", propertyValue="****"), @ActivationConfigProperty(propertyName="debug", propertyValue="true"), @ActivationConfigProperty(propertyName="starttls", propertyValue="false"), @ActivationConfigProperty(propertyName="pollingInterval", propertyValue="60000") }) @ResourceAdapter("mail-ra.rar") public class MailBean implements MailListener { public void onMessage(Message message) { // Process the message try { System.out.println("Message received:"+message.getSubject()); } catch (MessagingException e) { e.printStackTrace(); } } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

6
12
0 / 0

[JBoss JIRA] (AS7-5834) Convert WS subsystem to ResourceDefinition

by Tomaz Cerar (JIRA)

Tomaz Cerar created AS7-5834: -------------------------------- Summary: Convert WS subsystem to ResourceDefinition Key: AS7-5834 URL: https://issues.jboss.org/browse/AS7-5834 Project: Application Server 7 Issue Type: Sub-task Components: Domain Management, Web Services Reporter: Tomaz Cerar Assignee: Brian Stansberry Fix For: 7.2.0.CR1 Convert subsystem to use new APIs for defining the subsystem model -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
3
0 / 0

[JBoss JIRA] (JBREM-185) ability to configure keep-alive timeout

by Paul Hinds (JIRA)

[ https://issues.jboss.org/browse/JBREM-185?page=com.atlassian.jira.plugin.... ] Paul Hinds commented on JBREM-185: ---------------------------------- How was this resolved, where should the keepAliveTimeout be set? Documentation still indicates that keep-alive timeout is not configurable > ability to configure keep-alive timeout > --------------------------------------- > > Key: JBREM-185 > URL: https://issues.jboss.org/browse/JBREM-185 > Project: JBoss Remoting > Issue Type: Sub-task > Reporter: Tom Elrod > Assignee: Tom Elrod > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-5979) Make the root context of all HttpService-registered entities configurable

by David Bosschaert (JIRA)

David Bosschaert created AS7-5979: ------------------------------------- Summary: Make the root context of all HttpService-registered entities configurable Key: AS7-5979 URL: https://issues.jboss.org/browse/AS7-5979 Project: Application Server 7 Issue Type: Sub-task Components: OSGi, Web Affects Versions: 7.2.0.Alpha1 Reporter: David Bosschaert Assignee: David Bosschaert Fix For: 7.2.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-5976) The command :reload does not check the new configuration, and will cause server crashes if that config is broken

by Tom Fonteyne (JIRA)

Tom Fonteyne created AS7-5976: --------------------------------- Summary: The command :reload does not check the new configuration, and will cause server crashes if that config is broken Key: AS7-5976 URL: https://issues.jboss.org/browse/AS7-5976 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.2.Final (EAP) Reporter: Tom Fonteyne Assignee: Jason Greene The command :reload does not check the new configuration, and will cause server crashes if that config is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
1
0 / 0

[JBoss JIRA] (AS7-5254) Upgrade to infinispan 5.2

by Tomaz Cerar (JIRA)

Tomaz Cerar created AS7-5254: -------------------------------- Summary: Upgrade to infinispan 5.2 Key: AS7-5254 URL: https://issues.jboss.org/browse/AS7-5254 Project: Application Server 7 Issue Type: Component Upgrade Components: Clustering Affects Versions: 7.1.2.Final (EAP) Reporter: Tomaz Cerar Assignee: Paul Ferraro Fix For: 7.2.0.Alpha1 Infinispan 5.2 has some fixes that are needed for CapeDwarf to work properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
4
0 / 0

[JBoss JIRA] (AS7-5977) CLONE - The command :reload does not check the new configuration, and will cause server crashes if that config is broken

by Tom Fonteyne (JIRA)

Tom Fonteyne created AS7-5977: --------------------------------- Summary: CLONE - The command :reload does not check the new configuration, and will cause server crashes if that config is broken Key: AS7-5977 URL: https://issues.jboss.org/browse/AS7-5977 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.2.Final (EAP) Reporter: Tom Fonteyne Assignee: Jason Greene The command :reload does not check the new configuration, and will cause server crashes if that config is broken -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
0
0 / 0

[JBoss JIRA] (AS7-5970) RichFaces Showcase portlet is unable to switch skins

by Ken Finnigan (JIRA)

Ken Finnigan created AS7-5970: --------------------------------- Summary: RichFaces Showcase portlet is unable to switch skins Key: AS7-5970 URL: https://issues.jboss.org/browse/AS7-5970 Project: Application Server 7 Issue Type: Bug Components: JSF Affects Versions: 7.1.3.Final (EAP) Reporter: Ken Finnigan Assignee: Stan Silvert The following exception is thrown when the user changes skins for the second time immediately after changing the skin for the first time: {noformat} Caused by: javax.faces.FacesException: Cannot remove the same component twice: pbG9dea276d_2dee9e_2d4150_2dad91_2d22255b5a57d2_j_id1:j_idt444 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:489) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] at com.sun.faces.context.StateContext$AddRemoveListener.handleRemove(StateContext.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:334) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1] {noformat} This error manifests due to the Portlet Bridge needing to retain the UIViewRoot from JSF between Portlet Requests, which causes the list of component tree actions, ie. adding and removing, to be retained making JSF think that it's trying to remove a component that was actually removed in a previous request. This has been raised as http://java.net/jira/browse/JAVASERVERFACES-2609, but wanted to raise this as a tracker so that when that fix is available it can be incorporated. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
4
0 / 0

[JBoss JIRA] (AS7-5972) SharedLocalYieldingLockManager.LocalLock

by MJ Kim (JIRA)

MJ Kim created AS7-5972: --------------------------- Summary: SharedLocalYieldingLockManager.LocalLock Key: AS7-5972 URL: https://issues.jboss.org/browse/AS7-5972 Project: Application Server 7 Issue Type: Bug Components: Clustering Reporter: MJ Kim Assignee: Paul Ferraro Hi, Recently my system has been in the QA. (includes Stress test, Endurance test) During the endurance test, I found that the heap space was getting exausted, and not removed after full gc. When the heap space got close to 90%, the gabage collection was happend every 2 min, and my system was stopped reponding. The heap space was not cleaned up, nevertheless I ended the test (no request during a few hours) I downloaded some heap dumps, and found that the SharedLocalYieldingLockManage.LocalLock() resided much of heap space. (above 60%) I think the session expiration doesn't operate porperly. If the SessionBasesClusteredSession class raises the expiration signals with "LocalOnly=True", the lock would not be removed. Addionally, I reviewed our source code and did a leakage discory test, anything was matter. Here is my environment. If you want to see my standalone.xml, please post a reply thread. <Cluster> - 8 JVM (4 machine, each 2) - JDK : 1.6u31 - OS : Amazon Linux 64bit - JGroups : FILE_PING (The shared storage is GlusterFS volume) - Infinispan operation mode : L1 + Distribution / ASYNC / expiration 1min - Session handling : web.xml (expiration every 1min) (Originally our setting was 30 min. Beacuse the load generator was sending too many requests with new session, I lowered the threshold to 1min) - Source code : 7.1.3 Final tag (downloaded from Github) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

2
1
0 / 0

[JBoss JIRA] (JBRULES-3686) Wrong type declartion initialization causes an infinite loop when using property reactivity

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3686: ------------------------------------ Summary: Wrong type declartion initialization causes an infinite loop when using property reactivity Key: JBRULES-3686 URL: https://issues.jboss.org/browse/JBRULES-3686 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco A drl like the following with DataSample being annotated as @PropertyReactive ends up in an infinite loop even if it shouldn't. {{ rule 'Init' when $m: Model() then System.out.println("Inserting a DataSample"); insert(new DataSample($m)); end rule "Rule 1" when $m: Model() $d: DataSample(model == $m) then System.out.println(drools.getRule().getName()); modify($d){ addValue(Parameter.PARAM_A, 10.0) } end rule "Rule 2" when $m: Model() $d: DataSample(model == $m, $v: values[Parameter.PARAM_A] > 9.0) then System.out.println(drools.getRule().getName()); modify($d){ addMessage("Hello") } end rule "Data without messages" salience -100 when $m: Model() $d: DataSample(model == $m, messaged == false) then System.out.println(drools.getRule().getName()); end }} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
4
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 November 2012