[JBoss JIRA] Created: (JBREM-875) CLONE -Have ServerInvokerCallbackHandler register as connection listener [JBREM-873]
by Ron Sigal (JIRA)
CLONE -Have ServerInvokerCallbackHandler register as connection listener [JBREM-873]
------------------------------------------------------------------------------------
Key: JBREM-875
URL: http://jira.jboss.com/jira/browse/JBREM-875
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto), 2.2.0.SP2
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.2.2.SP4
This feature is implemented in response to JBPAPP-402 :"In certain situations createQueueConnection can hang".
JBossMessaging does not, in general, call org.jboss.remoting.callback.ServerInvokerCallbackHandler.destroy() when a lease indicates that a connection has failed. More generally, the need to call ServerCallbackHandler.destroy() is not documented in the Remoting Guide, so it is possible that JBossMessaging is not alone.
--
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, 3 months
[JBoss JIRA] Created: (JBREM-888) Client side connection exception is not thrown on the client side when the lease times out
by Jay Howell (JIRA)
Client side connection exception is not thrown on the client side when the lease times out
------------------------------------------------------------------------------------------
Key: JBREM-888
URL: http://jira.jboss.com/jira/browse/JBREM-888
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Reporter: Jay Howell
Clients that are connected that experience a lease timeout are not notified that they no longer have a connection on the server. The behavior is that clients think that they are alive, while they will no longer get any messages. Also something of note, the Server side pinger has been disabled for JBM.
Note: this is an issue that can either be fixed on the remoting side or the JBM side. Discussing this with Clebert, it may be prudent to fix it on both sides. I've opened this jira to facilitate the communication about where the logic should go. Please refer to the linked jira for the JBM ticket that was opened for this same topic.
--
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, 3 months
[JBoss JIRA] Created: (JBREM-891) ConnectionValidator should report if lease has expired
by Ron Sigal (JIRA)
ConnectionValidator should report if lease has expired
------------------------------------------------------
Key: JBREM-891
URL: http://jira.jboss.com/jira/browse/JBREM-891
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
Clebert Suconic wrote:
> You have this scenario:
>
> - Client is paused for 1 minute (say... a huge GC for example)
> - Server will invalidate that client (and close server side's objects)
> - Client comes back alive... it will then resume pings...
> - Nothing will invalidate the client, and the client became isolated).
Reply:
This isn't a Remoting bug. What you have described is Remoting behaving correctly, according to the current design.
1. On the server side, the lease mechanism can inform the application that the client is "unavailable".
2. On the client side, the ConnectionValidator can inform the application that the server is "unavailable".
One side or the other could be unavailable either because (1) it died or because (2) the network isn't functioning. In the first case, it doesn't make sense for one side to inform the other side of the failure, because there's no one on the other side to talk to. In the second case, both sides should see and report the same failure.
In the scenario you've described, the client isn't really unavailable - the apparent failure is just a timing artifact. The solution is to change the timing. I.e., extend the lease period.
Proposal:
If leasing is enabled on the server side, org.jboss.remoting.ServerInvoker, which responding to a PING from org.jboss.remoting.ConnectionValidator, should indicate if the lease is still alive.
--
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, 3 months
[JBoss JIRA] Created: (JBREM-895) MicroSocketClientInvoker.transport() must check for timeout after invocation attempt.
by Ron Sigal (JIRA)
MicroSocketClientInvoker.transport() must check for timeout after invocation attempt.
-------------------------------------------------------------------------------------
Key: JBREM-895
URL: http://jira.jboss.com/jira/browse/JBREM-895
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
Unit test org.jboss.test.remoting.callback.pull.CallbackPollerShutdownTestCase revealed a bug in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(). After the invocation attempt loop, there is a test to see if numberOfCallRetries has been exceeded. If so, the semaphore has already been released, and an exception is thrown. Another way the loop could end unsuccessfully is if a per invocation timeout has occurred. Currently, there is no test for this condition, so that semaphore.release() is called again, increasing the semaphore counter incorrectly.
--
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, 3 months
[JBoss JIRA] Created: (JBRULES-1437) DOT notation gives an error
by Toni Rikkola (JIRA)
DOT notation gives an error
---------------------------
Key: JBRULES-1437
URL: http://jira.jboss.com/jira/browse/JBRULES-1437
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 4.0.4
Reporter: Toni Rikkola
Following rule gave an java.lang.ClassCastException: org.drools.analytics.report.components.RedundancyShadowProxy cannot be cast to org.drools.analytics.components.RulePossibility exeption.
The bug was found when creating subsumption rules for analytics.
rule "Find subsumptant rule possibilities"
when
$redundancy :Redundancy(
left.causeType == CauseType.RULE,
$leftRuleId :left.id,
$rightRuleId :right.id
)
# Find two RulePossibilities.
$rp1 :RulePossibility(
ruleId == $leftRuleId
)
$rp2 :RulePossibility(
ruleId == $rightRuleId
)
# For every pattern possibility in $rp1 there is a redundant pattern possibility in $rp2.
forall(
$pp :PatternPossibility(
ruleId == $rp1.ruleId,
this memberOf $rp1.items
)
)
exists(
Subsumption(
)
or
Redundancy(
)
)
then
System.out.println("pim");
end
First tought that this was caused by or operator in exists, but tirelli found out that it is caused by a DOT notation.
--
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, 3 months