[JBoss JIRA] (JGRP-1821) SEQUENCER2: new impl of total order protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1821?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1821.
----------------------------
Resolution: Done
> SEQUENCER2: new impl of total order protocol
> --------------------------------------------
>
> Key: JGRP-1821
> URL: https://issues.jboss.org/browse/JGRP-1821
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When in {{SEQUENCER}} a member P wants to send a multicast message M, it unicasts it to the coordinator, who multicasts it on behalf of P.
> The new impl {{SEQUENCER2}} is different:
> * P asks the coord for a seqno
> * The coord responds with a (monotonically increasing) seqno
> * P multicasts M with that seqno
> * Everyone uses one global {{Table}} to deliver messages and weed out duplicates
> Advantages:
> # A sender sends messages itself, so the sequencer doesn't need to do sending (and potential retransmissions)
> # Compared to {{SEQUENCER}}, the data is only sent and marshalled once (better for large messages)
> # A sender grabs entire ranges of seqnos, so this should be efficient
> The edge case handling though requires some work, e.g.
> * A member B crashes after having received a seqno (e.g. 4)
> ** The sequencer will give out 5 next, but since nobody received 4, all subsequent messages will get stuck, waiting for 4
> * The sequencer (coord) dies or leaves
> ** The next-in-line probably needs to run some reconciliation protocol, asking all members for their highest received seqnos
> ** Messages like 4 would get marked as dummy, removed from table and dropped
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1821) SEQUENCER2: new impl of total order protocol
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1821?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1821:
--------------------------------
This impl needs more work in 4.0
> SEQUENCER2: new impl of total order protocol
> --------------------------------------------
>
> Key: JGRP-1821
> URL: https://issues.jboss.org/browse/JGRP-1821
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When in {{SEQUENCER}} a member P wants to send a multicast message M, it unicasts it to the coordinator, who multicasts it on behalf of P.
> The new impl {{SEQUENCER2}} is different:
> * P asks the coord for a seqno
> * The coord responds with a (monotonically increasing) seqno
> * P multicasts M with that seqno
> * Everyone uses one global {{Table}} to deliver messages and weed out duplicates
> Advantages:
> # A sender sends messages itself, so the sequencer doesn't need to do sending (and potential retransmissions)
> # Compared to {{SEQUENCER}}, the data is only sent and marshalled once (better for large messages)
> # A sender grabs entire ranges of seqnos, so this should be efficient
> The edge case handling though requires some work, e.g.
> * A member B crashes after having received a seqno (e.g. 4)
> ** The sequencer will give out 5 next, but since nobody received 4, all subsequent messages will get stuck, waiting for 4
> * The sequencer (coord) dies or leaves
> ** The next-in-line probably needs to run some reconciliation protocol, asking all members for their highest received seqnos
> ** Messages like 4 would get marked as dummy, removed from table and dropped
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1687) CastMessageWithFuture in MessageDispatcher
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1687?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1687.
----------------------------
Resolution: Done
Merged onto master (3.5), will not get backported to the 3.4 branch
> CastMessageWithFuture in MessageDispatcher
> -------------------------------------------
>
> Key: JGRP-1687
> URL: https://issues.jboss.org/browse/JGRP-1687
> Project: JGroups
> Issue Type: Bug
> Reporter: shen kim
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When I used CastMessageWithFuture in MessageDispatcher. I found the following Method declared :
> public <T> NotifyingFuture<RspList<T>> castMessageWithFuture(java.util.Collection<Address> dests, Message RequestOptions options, FutureListener<T> listener) throws java.lang.Exception
> Is it the FutureListener<T> may be declared to FutureListener<RspList<T>> ?
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-921) Context initialization exceptions are swallowed on deployment
by Jarkko Rantavuori (JIRA)
[ https://issues.jboss.org/browse/WFLY-921?page=com.atlassian.jira.plugin.s... ]
Jarkko Rantavuori commented on WFLY-921:
----------------------------------------
Ok, tested with EAP 6.2.0 and I am able to see the error message properly.
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: WFLY-921
> URL: https://issues.jboss.org/browse/WFLY-921
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Environment: Windows 7
> Reporter: Jarkko Rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1827) Forked channel requires udp.xml file
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1827?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1827.
----------------------------
Resolution: Done
> Forked channel requires udp.xml file
> ------------------------------------
>
> Key: JGRP-1827
> URL: https://issues.jboss.org/browse/JGRP-1827
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Environment: Android
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4, 3.5
>
> Attachments: bla2.java, fork-stacks.xml, main.xml
>
>
> An exception is thrown when creating a fork channel if the stack file name is something other than udp.xml (in my case main.xml):
> final JChannel mainChannel = new JChannel("main.xml");
> final ForkChannel mbChannel = new ForkChannel(mainChannel,
> "main", "fork-mb");
> 4-09 17:33:38.270: W/System.err(5478): java.io.FileNotFoundException: JGRP000003: file "udp.xml" not found
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:211)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:102)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:172)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:123)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:75)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:118)
> 04-09 17:33:38.270: W/System.err(5478): at com.novawurks.jgroupstest.JGroupsTestActivity$JGroupsSetupThread.run(JGroupsTestActivity.java:119)
> If I have the stack named udp.xml then the exception is not thrown and everything works as expected. If I make a copy of main.xml named udp.xml (so both files are present) the exception is not thrown and everything works as expected.
> Contents of main.xml / udp.xml :
> {code:xml}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd" >
> <UDP
> enable_diagnostics="true"
> ip_mcast="true"
> ip_ttl="${jgroups.udp.ip_ttl:8}"
> loopback="true"
> max_bundle_size="1400"
> max_bundle_timeout="5"
> mcast_port="${jgroups.udp.mcast_port:45588}"
> mcast_recv_buf_size="200K"
> mcast_send_buf_size="200K"
> oob_thread_pool.enabled="true"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.min_threads="1"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="discard"
> thread_naming_pattern="cl"
> thread_pool.enabled="true"
> thread_pool.keep_alive_time="5000"
> thread_pool.max_threads="8"
> thread_pool.min_threads="2"
> thread_pool.queue_enabled="true"
> thread_pool.queue_max_size="10000"
> thread_pool.rejection_policy="discard"
> timer.keep_alive_time="3000"
> timer.max_threads="10"
> timer.min_threads="4"
> timer.queue_max_size="500"
> timer_type="new3"
> tos="8"
> ucast_recv_buf_size="200K"
> ucast_send_buf_size="200K" />
> <PING />
> <MERGE2
> max_interval="30000"
> min_interval="10000" />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2
> discard_delivered_msgs="true"
> max_msg_batch_size="500"
> use_mcast_xmit="false"
> xmit_interval="500"
> xmit_table_max_compaction_time="30000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <UNICAST3
> conn_expiry_timeout="0"
> max_msg_batch_size="500"
> xmit_interval="500"
> xmit_table_max_compaction_time="60000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <pbcast.STABLE
> desired_avg_gossip="50000"
> max_bytes="4M"
> stability_delay="1000" />
> <pbcast.GMS
> join_timeout="3000"
> print_local_addr="true"
> view_bundling="true" />
> <UFC
> max_credits="2M"
> min_threshold="0.4" />
> <MFC
> max_credits="2M"
> min_threshold="0.4" />
> <FRAG frag_size="1000" />
> <pbcast.STATE_TRANSFER />
> <FORK>
> <fork-stack id="main" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> </config>
> </fork-stack>
> <fork-stack id="lock" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> <STATS />
> </config>
> </fork-stack>
> </FORK>
> </config>
> {code}
--
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
10 years, 5 months
[JBoss JIRA] (JGRP-1827) Forked channel requires udp.xml file
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1827?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1827:
--------------------------------
Fixed by calling super(false) which prevents udp.xml from being used
> Forked channel requires udp.xml file
> ------------------------------------
>
> Key: JGRP-1827
> URL: https://issues.jboss.org/browse/JGRP-1827
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.1
> Environment: Android
> Reporter: Jim Thomas
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.4, 3.5
>
> Attachments: bla2.java, fork-stacks.xml, main.xml
>
>
> An exception is thrown when creating a fork channel if the stack file name is something other than udp.xml (in my case main.xml):
> final JChannel mainChannel = new JChannel("main.xml");
> final ForkChannel mbChannel = new ForkChannel(mainChannel,
> "main", "fork-mb");
> 4-09 17:33:38.270: W/System.err(5478): java.io.FileNotFoundException: JGRP000003: file "udp.xml" not found
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:211)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:102)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:172)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.JChannel.<init>(JChannel.java:123)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:75)
> 04-09 17:33:38.270: W/System.err(5478): at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:118)
> 04-09 17:33:38.270: W/System.err(5478): at com.novawurks.jgroupstest.JGroupsTestActivity$JGroupsSetupThread.run(JGroupsTestActivity.java:119)
> If I have the stack named udp.xml then the exception is not thrown and everything works as expected. If I make a copy of main.xml named udp.xml (so both files are present) the exception is not thrown and everything works as expected.
> Contents of main.xml / udp.xml :
> {code:xml}
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd" >
> <UDP
> enable_diagnostics="true"
> ip_mcast="true"
> ip_ttl="${jgroups.udp.ip_ttl:8}"
> loopback="true"
> max_bundle_size="1400"
> max_bundle_timeout="5"
> mcast_port="${jgroups.udp.mcast_port:45588}"
> mcast_recv_buf_size="200K"
> mcast_send_buf_size="200K"
> oob_thread_pool.enabled="true"
> oob_thread_pool.keep_alive_time="5000"
> oob_thread_pool.max_threads="8"
> oob_thread_pool.min_threads="1"
> oob_thread_pool.queue_enabled="false"
> oob_thread_pool.queue_max_size="100"
> oob_thread_pool.rejection_policy="discard"
> thread_naming_pattern="cl"
> thread_pool.enabled="true"
> thread_pool.keep_alive_time="5000"
> thread_pool.max_threads="8"
> thread_pool.min_threads="2"
> thread_pool.queue_enabled="true"
> thread_pool.queue_max_size="10000"
> thread_pool.rejection_policy="discard"
> timer.keep_alive_time="3000"
> timer.max_threads="10"
> timer.min_threads="4"
> timer.queue_max_size="500"
> timer_type="new3"
> tos="8"
> ucast_recv_buf_size="200K"
> ucast_send_buf_size="200K" />
> <PING />
> <MERGE2
> max_interval="30000"
> min_interval="10000" />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2
> discard_delivered_msgs="true"
> max_msg_batch_size="500"
> use_mcast_xmit="false"
> xmit_interval="500"
> xmit_table_max_compaction_time="30000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <UNICAST3
> conn_expiry_timeout="0"
> max_msg_batch_size="500"
> xmit_interval="500"
> xmit_table_max_compaction_time="60000"
> xmit_table_msgs_per_row="2000"
> xmit_table_num_rows="100" />
> <pbcast.STABLE
> desired_avg_gossip="50000"
> max_bytes="4M"
> stability_delay="1000" />
> <pbcast.GMS
> join_timeout="3000"
> print_local_addr="true"
> view_bundling="true" />
> <UFC
> max_credits="2M"
> min_threshold="0.4" />
> <MFC
> max_credits="2M"
> min_threshold="0.4" />
> <FRAG frag_size="1000" />
> <pbcast.STATE_TRANSFER />
> <FORK>
> <fork-stack id="main" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> </config>
> </fork-stack>
> <fork-stack id="lock" >
> <config>
> <CENTRAL_LOCK num_backups="2" />
> <STATS />
> </config>
> </fork-stack>
> </FORK>
> </config>
> {code}
--
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
10 years, 5 months
[JBoss JIRA] (WFLY-921) Context initialization exceptions are swallowed on deployment
by Jarkko Rantavuori (JIRA)
[ https://issues.jboss.org/browse/WFLY-921?page=com.atlassian.jira.plugin.s... ]
Jarkko Rantavuori commented on WFLY-921:
----------------------------------------
What about EAP? Should a separate issue be opened for that?
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: WFLY-921
> URL: https://issues.jboss.org/browse/WFLY-921
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Environment: Windows 7
> Reporter: Jarkko Rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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
10 years, 5 months