[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
[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
[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
[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