[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from ASSIGNED to ON_QA
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1362) NAKACK: second line of defense for requested retransmissions that are not found
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1362?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1362:
---------------------------
Fix Version/s: 3.6.8
(was: Future)
This problem never occurred
> NAKACK: second line of defense for requested retransmissions that are not found
> -------------------------------------------------------------------------------
>
> Key: JGRP-1362
> URL: https://issues.jboss.org/browse/JGRP-1362
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.8
>
>
> When the original sender B is asked by A to retransmit message M, but doesn't have M in its retransmission table anymore, it should tell A, or else A will send retransmission requests to B until A or B leave.
> This problem should have been fixed by JGRP-1251, but if it turns out it wasn't, then this JIRA is (1) a second line of defense to stop the endless retransmission requests and (2) will give us valuable diagnostic information to fix the underlying problem (should there still be one).
> Problem:
> - A has a NakReceiverWindow (NRW) of 50 (highest_delivered seqno) for B
> - B's NRW, however, is 200. B garbage collected messages up to 150.
> - When B sends message 201, A will ask B for retransmission of [51-200]
> - B will retransmit messages [150-200], but it cannot send messages 51-149, as it doesn't have them anymore !
> - A will add messages [150-200], but its NRW is still 50 (highest_delivered)
> - A will continue asking B for messages [51-149] (it does have [150-201])
> - This will go on forever, or until B or A leaves
> SOLUTION:
> - When the *original sender* B of message M receives a retransmission request for M (from A), and it doesn't have M in its retransmission table, it should send back a MSG_NOT_FOUND message to A including B's digest
> - When A receives the MSG_NOT_FOUND message, it does the following:
> - It logs it own NRW for B
> - It logs B's digest
> - It logs its digest history
> (This information is valuable for investigating the underlying issue)
> - Then A's NRW for B is adjusted:
> - The highest_delivered seqno is set to B.digest.highest_delivered
> - All messages in xmit_table below B.digest.highest_delivered are removed
> - All retransmission tasks in the retransmitter <= B.digest.highest_delivered are cancelled and removed
> (This will stop the retransmission)
> Again, this is a second line of defense, which should never be used. If the underlying problem does occur, however, we'll have valuable information in the logs to diagnose what went wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1362) NAKACK: second line of defense for requested retransmissions that are not found
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1362?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1362.
--------------------------
Resolution: Cannot Reproduce
> NAKACK: second line of defense for requested retransmissions that are not found
> -------------------------------------------------------------------------------
>
> Key: JGRP-1362
> URL: https://issues.jboss.org/browse/JGRP-1362
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.8
>
>
> When the original sender B is asked by A to retransmit message M, but doesn't have M in its retransmission table anymore, it should tell A, or else A will send retransmission requests to B until A or B leave.
> This problem should have been fixed by JGRP-1251, but if it turns out it wasn't, then this JIRA is (1) a second line of defense to stop the endless retransmission requests and (2) will give us valuable diagnostic information to fix the underlying problem (should there still be one).
> Problem:
> - A has a NakReceiverWindow (NRW) of 50 (highest_delivered seqno) for B
> - B's NRW, however, is 200. B garbage collected messages up to 150.
> - When B sends message 201, A will ask B for retransmission of [51-200]
> - B will retransmit messages [150-200], but it cannot send messages 51-149, as it doesn't have them anymore !
> - A will add messages [150-200], but its NRW is still 50 (highest_delivered)
> - A will continue asking B for messages [51-149] (it does have [150-201])
> - This will go on forever, or until B or A leaves
> SOLUTION:
> - When the *original sender* B of message M receives a retransmission request for M (from A), and it doesn't have M in its retransmission table, it should send back a MSG_NOT_FOUND message to A including B's digest
> - When A receives the MSG_NOT_FOUND message, it does the following:
> - It logs it own NRW for B
> - It logs B's digest
> - It logs its digest history
> (This information is valuable for investigating the underlying issue)
> - Then A's NRW for B is adjusted:
> - The highest_delivered seqno is set to B.digest.highest_delivered
> - All messages in xmit_table below B.digest.highest_delivered are removed
> - All retransmission tasks in the retransmitter <= B.digest.highest_delivered are cancelled and removed
> (This will stop the retransmission)
> Again, this is a second line of defense, which should never be used. If the underlying problem does occur, however, we'll have valuable information in the logs to diagnose what went wrong.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-1194) Revisit implementation of TUNNEL and shared transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1194?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1194:
---------------------------
Fix Version/s: 3.6.8
(was: Future)
Moot with the deprecation of shared transports and advent of fork channels
> Revisit implementation of TUNNEL and shared transport
> -----------------------------------------------------
>
> Key: JGRP-1194
> URL: https://issues.jboss.org/browse/JGRP-1194
> Project: JGroups
> Issue Type: Task
> Affects Versions: 2.8, 2.9
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
> Fix For: 3.6.8
>
>
> TUNNEL and shared transport are not supported at the moment (2.10.Alpha5). The main complexity behind TUNNEL and shared transport is that we have to change StubReceiver model. StubReceiver reads messages of the socket on the TUNNEL side. With shared transport turned on StubReceiver would have to be changed because we are receiving byte arrays for all channels sharing transport. We need some special StubReceiver multiplexer so to speak which will read messages and then pass off the byte arrays to other Receivers which will in turn pass them as messages to appropriate channel above transport. Each byte array passed around have to be pre appended with some identifier....and so on.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-965) Message: headers are not copied
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-965?page=com.atlassian.jira.plugin.s... ]
Bela Ban closed JGRP-965.
-------------------------
Resolution: Cannot Reproduce
> Message: headers are not copied
> -------------------------------
>
> Key: JGRP-965
> URL: https://issues.jboss.org/browse/JGRP-965
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.8
>
>
> Message.copy() uses Headers.copy() which does *not* copy the headers but just uses refs. This might cause unintended side effects, investigate whether this is okay or not.
> Example: we have a message in a retransmission table. We might copy it on retransmissio and change a header, that change will then be made in the original header.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-844) Discovery: make it a singleton with a shared transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-844?page=com.atlassian.jira.plugin.s... ]
Bela Ban updated JGRP-844:
--------------------------
Fix Version/s: 3.6.8
(was: Future)
Not needed anymore with fork channels
> Discovery: make it a singleton with a shared transport
> ------------------------------------------------------
>
> Key: JGRP-844
> URL: https://issues.jboss.org/browse/JGRP-844
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.8
>
>
> When we have a shared transport and 5 channels on top of it, then every channel will run the discovery protocol. If it is the first node in a cluster, this will take <5 * Discovery.timeout> ms.
> Now, if the 5 channels didn't just share the transport, but also the discovery protocol, then only the first channel to start would have to wait for Discovery.timeout ms. It would then cache the results of that discovery and, when view changes are received, replace the contents of the cache with view information.
> The remaining 4 channels would then not even need to run the discovery phase, but the discovery protocol would simply use the current view to return the coordinator. This means that instead of 5 * timeout, we have 1 * timeout !
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-844) Discovery: make it a singleton with a shared transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-844?page=com.atlassian.jira.plugin.s... ]
Bela Ban closed JGRP-844.
-------------------------
Resolution: Won't Do
> Discovery: make it a singleton with a shared transport
> ------------------------------------------------------
>
> Key: JGRP-844
> URL: https://issues.jboss.org/browse/JGRP-844
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.8
>
>
> When we have a shared transport and 5 channels on top of it, then every channel will run the discovery protocol. If it is the first node in a cluster, this will take <5 * Discovery.timeout> ms.
> Now, if the 5 channels didn't just share the transport, but also the discovery protocol, then only the first channel to start would have to wait for Discovery.timeout ms. It would then cache the results of that discovery and, when view changes are received, replace the contents of the cache with view information.
> The remaining 4 channels would then not even need to run the discovery phase, but the discovery protocol would simply use the current view to return the coordinator. This means that instead of 5 * timeout, we have 1 * timeout !
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (JGRP-965) Message: headers are not copied
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-965?page=com.atlassian.jira.plugin.s... ]
Bela Ban updated JGRP-965:
--------------------------
Fix Version/s: 3.6.8
(was: Future)
> Message: headers are not copied
> -------------------------------
>
> Key: JGRP-965
> URL: https://issues.jboss.org/browse/JGRP-965
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.8
>
>
> Message.copy() uses Headers.copy() which does *not* copy the headers but just uses refs. This might cause unintended side effects, investigate whether this is okay or not.
> Example: we have a message in a retransmission table. We might copy it on retransmissio and change a header, that change will then be made in the original header.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months