[JBoss JIRA] Created: (JGRP-647) Potentially Meaningless InterruptedIOException Can Be Logged Repeatedly
by Jimmy Wilson (JIRA)
Potentially Meaningless InterruptedIOException Can Be Logged Repeatedly
-----------------------------------------------------------------------
Key: JGRP-647
URL: http://jira.jboss.com/jira/browse/JGRP-647
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6, 2.5.1, 2.5, 2.4.1 SP4, 2.4.1 SP3
Reporter: Jimmy Wilson
Assigned To: Bela Ban
Priority: Minor
Fix For: 2.4.2, 2.7
TP.down doesn't catch/handle the InterruptedIOException that can be thrown from the underlying send call when interrupted:
try {
if(use_outgoing_packet_handler)
outgoing_queue.put(msg);
else
send(msg, dest, multicast);
}
catch(QueueClosedException closed_ex) {
}
catch(InterruptedException interruptedEx) {
}
catch(Throwable e) {
if(log.isErrorEnabled()) {
String dst=msg.getDest() == null? "null" : msg.getDest().toString();
log.error("failed sending message to " + dst + " (" + msg.getLength() + " bytes)", e.getCause());
}
}
This can lead to it being logged repeatedly at the ERROR level:
2007-11-14 10:02:30,040 ERROR -> (PingSender) [UDP] failed sending message to null (0 bytes)
java.io.InterruptedIOException: operation interrupted
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:612)
at org.jgroups.protocols.UDP._send(UDP.java:316)
at org.jgroups.protocols.UDP.sendToAllMembers(UDP.java:286)
at org.jgroups.protocols.TP.doSend(TP.java:937)
at org.jgroups.protocols.TP.send(TP.java:926)
at org.jgroups.protocols.TP.down(TP.java:712)
at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:499)
at org.jgroups.stack.Protocol.passDown(Protocol.java:533)
at org.jgroups.protocols.PING.sendMcastDiscoveryRequest(PING.java:214)
at org.jgroups.protocols.PING.sendGetMembersRequest(PING.java:208)
at org.jgroups.protocols.PingSender.run(PingSender.java:59)
at java.lang.Thread.run(Thread.java:595)
2.5/2.6 don't handle the InterruptedIOException either, but since this was reported with EAP 4.2 (JGroups 2.4.1.SP3), I 'd like to see it in 2.4.2 if possible. That way, it can make it into a 4.2/4.3 EAP CP.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JGRP-557) MuxChannel should not receive views after it disconnects
by Vladimir Blagojevic (JIRA)
MuxChannel should not receive views after it disconnects
--------------------------------------------------------
Key: JGRP-557
URL: http://jira.jboss.com/jira/browse/JGRP-557
Project: JGroups
Issue Type: Bug
Affects Versions: 2.5
Reporter: Vladimir Blagojevic
Assigned To: Bela Ban
Brian Stansberry said:
Noticed a behavior difference between a MuxChannel and a regular JChannel. If a service uses a regular JChannel and calls disconnect, it does not get a viewAccepted callback with the new view that excludes itself. If the service uses a MuxChannel, it does get the callback.
I have a vague memory that this came up in discussions a long time ago (and that maybe we decided to ignore it???). Couldn't find anything in the archive though. In a way it's nice to get the view, but if we leave this as is, services that can handle either type of channel (e.g. JBoss Cache) will need to properly handle both cases.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBRULES-1315) Rule that uses a 'collect' and 'from' clause together causes problem
by Igor Bolic (JIRA)
Rule that uses a 'collect' and 'from' clause together causes problem
--------------------------------------------------------------------
Key: JBRULES-1315
URL: http://jira.jboss.com/jira/browse/JBRULES-1315
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.3
Reporter: Igor Bolic
Test case:
Write a Rule that uses a 'collect' and 'from' clause together, example:
package com.sample.mypackage
rule "Apply discount"
when
$order: Order();
$items : ArrayList() from collect (OrderItem() from $order.items)
then
#apply discount
end
first i add the package to RuleBase object, everthing works fine. When i try to 'refresh' my rules, i.e. first remove the package and again
add the same (modified) package to the RuleBase object, following error occurs:
java.lang.IllegalArgumentException: Cannot remove a sink, when the list of sinks is null
at org.drools.reteoo.ObjectSource.removeObjectSink(ObjectSource.java:116)
at org.drools.reteoo.AlphaNode.remove(AlphaNode.java:181)
at org.drools.reteoo.LeftInputAdapterNode.remove(LeftInputAdapterNode.java:204)
at org.drools.reteoo.FromNode.remove(FromNode.java:153)
at org.drools.reteoo.RightInputAdapterNode.remove(RightInputAdapterNode.java:167)
at org.drools.reteoo.BetaNode.remove(BetaNode.java:186)
at org.drools.reteoo.RuleTerminalNode.remove(RuleTerminalNode.java:461)
at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:224)
at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:272)
at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:460)
...
I've found a workaround for this error by writing my .drl code as following:
package com.sample.mypackage
rule "Explode Cart"
salience 11
dialect "java"
when
$order: Order()
$item : OrderItem() from $order.items
then
insert( $item );
end
rule "Apply discount"
no-loop true
when
$order : Order();
$items : ArrayList() from collect (OrderItem())
then
#apply discount
end
Now, my rules are 'refreshed' without any error.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBAS-4215) Need to externalize the web container class loader to use outside of the web container
by Scott M Stark (JIRA)
Need to externalize the web container class loader to use outside of the web container
--------------------------------------------------------------------------------------
Key: JBAS-4215
URL: http://jira.jboss.com/jira/browse/JBAS-4215
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Deployment services, Web (Tomcat) service
Reporter: Scott M Stark
Assigned To: Dimitris Andreadis
Fix For: JBossAS-5.0.0.Beta3
We need a WarClassLoadingDeployer that allows for the creation of the web container class loader during the DeploymentUnit processing based on the class loading metadata. In the absence of jboss UCL or osgi bundle metadata, this should create the standard tomcat war first class loader. Not having this at the DeploymentUnit level does not allow other deployers to interact with war deployments properly.
--
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
16 years, 11 months
[JBoss JIRA] Created: (JBAS-3883) JBoss ignores "Class-Path" attribute in WAR's MANIFEST.MF
by Amit Kasher (JIRA)
JBoss ignores "Class-Path" attribute in WAR's MANIFEST.MF
---------------------------------------------------------
Key: JBAS-3883
URL: http://jira.jboss.com/jira/browse/JBAS-3883
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading, Web (Tomcat) service
Affects Versions: JBossAS-5.0.0.Beta1
Reporter: Amit Kasher
Assigned To: Scott M Stark
An EAR file that deploys well in JBoss4.0.5 fails to deploy in JBoss5.0Beta1 when initializing the web application (NoClassDefFound).
However, this ear does deploy well when taking the required jar files (the WAR dependencies) out of the EAR and placing them inside the .war/WEB-INF/lib folder, as well as removing the "Class-Path" entry in the WAR's MANIFEST.MF.
Documents stating, as far as I understand, the existence of the requirement that this should work are here:
http://java.sun.com/j2ee/verified/packaging.html
... as well as in the spec ... (http://jcp.org/en/jsr/detail?id=244) in section EE.8.2.1 (Bundled Libraries) starting in page 155.
It's related to Tomcat's classpath (or to the classpath augmentation JBoss performs, where there were probably recent changes to support resource injection into web clients, like servlets). This is why I indicated Tomcat as an additional affected component.
--
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
16 years, 11 months