[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:04 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code:xml}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:03 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1828:
--------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1828) Allow protocols to define inline XML config
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1828?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1828 at 4/18/14 8:01 AM:
---------------------------------------------------------
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
was (Author: belaban):
The schema additiona would be (at the top level of the schema):
{code:xml}
<xs:complexType name="ForkStack">
<xs:sequence>
<xs:element name="config" type="ConfigType"/>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
{code}
and
{code:xml}
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
{code}
or, alternatively:
{code:xml}
<xs:element name="fork-stacks" xmlns="fork-stacks" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="fork-stacks "/>
{code}
The latter would reuse the already existing schema {{fork-stacks.xsd}}.
The (abridged) schema version of FORK would look like this:
{code}
<xs:element name="FORK">
<xs:complexType>
<xs:attribute name="config" type="xs:string">
</xs:attribute>
<xs:attribute name="stats" type="xs:string">
<xs:attribute name="name" type="xs:string">
...
<xs:element name="fork-stacks">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="fork-stack" type="ForkStack"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:complexType>
</xs:element>
{code:xml}
> Allow protocols to define inline XML config
> -------------------------------------------
>
> Key: JGRP-1828
> URL: https://issues.jboss.org/browse/JGRP-1828
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> Some protocols (e.g. RELAY2 or FORK) need additional configuration, which is usually defined in a separate XML file, e.g.
> {code:xml}
> <FORK config="/home/bela/fork-stacks.xml"/>
> {code}
> File {{fork-stacks.xml}} is:
> {code:xml}
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> {code}
> It would be nice to be able to optionally define such additional configuration inline, e.g.
> {code:xml}
> <FORK>
> <fork-stacks xmlns="fork-stacks">
> <fork-stack id="counter">
> <config>
> <COUNTER bypass_bundling="true"/>
> <COMPRESS/>
> </config>
> </fork-stack>
> <fork-stack id="locking">
> <config>
> <CENTRAL_LOCK num_backups="2"/>
> </config>
> </fork-stack>
> </fork-stacks>
> </FORK>
> {code}
> As the schema for config files is *generated*, we would have to able to tell the generator ({{XMLSchemaGenerator}}) to include a schema fragment defined by any protocol.
> A schema fragment could be defined via an annotation, e.g. {{@IncludeSchema(schema="fork-stacks.xsd"}}.
> Investigate whether this is feasible.
--
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
12 years, 3 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 edited comment on JGRP-1827 at 4/18/14 7:21 AM:
---------------------------------------------------------
I'll take another look. Do you have a small sample program that shows the behavior ? I can't correlate your stack trace to the src as this is your port to Android to which I don't have the src code...
I'll also need the XML config plus the config of the fork stacks. I hope you don't still have the fork stack config inline...
was (Author: belaban):
I'll take another look. Do you have a small sample program that shows the behavior ? I can't correlate your stack trace to the src as this is your port to Android to which I don't have the src code...
> 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
12 years, 3 months
[JBoss JIRA] (WFLY-3273) wildfly-service.exe is not working in 32 bit system-unable to start the service
by shaik masthan (JIRA)
shaik masthan created WFLY-3273:
-----------------------------------
Summary: wildfly-service.exe is not working in 32 bit system-unable to start the service
Key: WFLY-3273
URL: https://issues.jboss.org/browse/WFLY-3273
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Scripts, Server
Affects Versions: 8.0.0.Final, 8.0.0.CR1
Environment: operating system -windows 2003 server , software - JAVA, (32 BIT JDK) SERVER-WILD-FLY 8.0.0 Final
Reporter: shaik masthan
Assignee: Tomaz Cerar
Fix For: 8.0.0.Final
i tried to register the wild-fly as a windows service using "service.bat" file (x86-32 bit system) ,successfully registered as a service and able to start up the service.
but when i use the "wildfly-service.exe" it is register as a service but unable to start up the service , "always getting the error message "failed to start the service".
i tried passing the command line options "--jvm,--Classpath,--JavaHome" etc while start up the service , but did not work .
please let us know any work around for this or is it a bug in wildfly
thanks
masthan
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-3273) wildfly-service.exe is not working in 32 bit system-unable to start the service
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3273?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3273:
------------------------------
Fix Version/s: (was: 8.0.0.Final)
> wildfly-service.exe is not working in 32 bit system-unable to start the service
> -------------------------------------------------------------------------------
>
> Key: WFLY-3273
> URL: https://issues.jboss.org/browse/WFLY-3273
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts, Server
> Affects Versions: 8.0.0.CR1, 8.0.0.Final
> Environment: operating system -windows 2003 server , software - JAVA, (32 BIT JDK) SERVER-WILD-FLY 8.0.0 Final
> Reporter: shaik masthan
> Assignee: Tomaz Cerar
> Labels: wildfly-windowsservice
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> i tried to register the wild-fly as a windows service using "service.bat" file (x86-32 bit system) ,successfully registered as a service and able to start up the service.
> but when i use the "wildfly-service.exe" it is register as a service but unable to start up the service , "always getting the error message "failed to start the service".
> i tried passing the command line options "--jvm,--Classpath,--JavaHome" etc while start up the service , but did not work .
> please let us know any work around for this or is it a bug in wildfly
> thanks
> masthan
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1829) Failing to connect to an unavailable member blocks all message sending
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1829?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1829:
--------------------------------
{quote}
What's the expected timetable for JGroups 4.0? I suppose that it's behind JGroups 3.5 - of course! - and so some way off yet.
{quote}
Yes, it'll be a while until I even start working on 4.0. After releasing 3.5 I plan on working on a deep dive course on JGroups and only then will I start looking at 4.
{quote}
I had hoped that you'd want to make a fix to this one before that. I guess I'd had in mind something like:
* if we need to get a new connection while trying a send() then put the the message that we're sending onto a queue
* continue opening the connection in a new thread (so the original thread is unblocked)
* while the queue for some destination is non-empty, queue all messages to it so as to preserve ordering
* when the connect completes (either successfully or not) process the queued messages
I understand that this is a bit vague and the devil is in the details - but something along these lines should be possible, shouldn't it?
{quote}
This is not something I'm interested in as it is throw-away work and would get replaced in 4.0 anyway. You could do this yourself, though, and patch your system until 4.0 comes around. If your patch works, I could even decide to accept this into the main code base.
{quote}
Your suggestion to use UDP is interesting. I think we're probably using TCP only because I'd assumed that TCPPING would need TCP transport. But I can't immediately see why TCPPING wouldn't work fine with UDP transport. Is that right?
{quote}
Yes, UDP with ip_mcast=false works with TCPPING, but also with other discovery protocols such as FILE_PING, TCPGOSSIP, S3_PING, GOOGLE_PING etc. One could even think of coming up with a UDPPING if needed...
I once tested {{UDP(ip_mcast=false):TCPPING}} on EC2 and it worked. I have yet to test it on Google Compute Engine, but I don't see why it wouldn't work
{quote}
Still, I'd prefer to explore a fix. A change in transport feels like a much bigger change for us and would require quite a bit more testing than a targeted fix. Also, a fix would make JGroups better - and that must be good, right?
{quote}
Are you referring to the fix you described above ? If you want to do that, go ahead. But this is temporary, until 4.0 comes around.
> Failing to connect to an unavailable member blocks all message sending
> ----------------------------------------------------------------------
>
> Key: JGRP-1829
> URL: https://issues.jboss.org/browse/JGRP-1829
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.2
> Reporter: David Hotham
> Assignee: Bela Ban
>
> Hi,
> We're seeing a problem which appears to be caused by the TransferQueueBundler thread being blocked while it fails to connect to an unavailable member.
> The setup we have is a cluster split across two sites: say, members 0 through 4 in site A and members 5 through 9 in site B. Initially the cluster is complete: everyone has the same view. The case that we're testing is: what happens when connectivity is lost between the sites? NB we're using TCP transport.
> Obviously the expected result is that we'd get two sub-clusters, one in each site. But this doesn't always happen. Instead we sometimes see some members become singletons (that is, with only themselves in view).
> What seems to be happening is something like this:
> - When the cross-site link is cut, members in site A suspect members in site B (and vice versa).
> - So in each site there's a broadcast of SUSPECT messages
> - Now each of the members in site A tries to VERIFY_SUSPECT each of the members in site B
> - Each such attempt blocks the TransferQueueBundler for two seconds (TCP's default sock_conn_timeout), because we can't contact any member in the other site
> - But that introduces a delay for _all_ messages, not only for messages to the 'other' site
> - If there are enough members in the 'other' site, we can easily get a large enough delay that HEARTBEAT (and then VERIFY_SUSPECT) messages start timing out between members in the same site
> - At this point, members that ought to be able to see one another start to report that they cannot do so.
> We've seen cases where a member becomes completely isolated - forming a singleton cluster - and does not recover. Unfortunately we don't have full trace from that run, so it's not clear why the cluster didn't eventually recover. I suspect that we're hitting something like JGRP-1493, in which delays sending messages (in that case, a delay when failing to get a physical address) caused the MergeKiller always to prevent merging.
> It is highly undesirable that when a cluster contains several unavailable members, as in a partition between two sites, this should cause problems for members that can see one another.
> Should all message sending really be blocked while failing to connect to an unavailable member?
> This issue seems related also to JGRP-1815 which raises a similar question: should all message sending really be blocked while failing to find a physical address?
> What do you think?
> - do you agree that blocking message sending while attempting to connect to an unavailable member is undesirable?
> - if so, what do you think the right fix is? If it's not too hard, we may be able to find time to take a look at implementing this ourselves.
> - is there anything else we can do to help progress this issue?
> We're using JGroups 3.4.2. I've attached the code fragment with which we configure the stack below.
> Thanks for your help
> David
> {noformat}
> stack.addProtocol((new TCP)
> .setValue("enable_diagnostics", false)
> .setValue("logical_addr_cache_max_size", 70)
> .setValue("logical_addr_cache_expiration", 10000)
> .setValue("physical_addr_max_fetch_attempts", 1)
> .setValue("bind_addr", localAddr)
> .setValue("bind_port", basePort)
> .setValue("port_range", 0))
> val tcpping = new TCPPING
> val jhosts = initialHosts map { addr => new IpAddress(addr.getHostAddress, basePort) }
> tcpping.setInitialHosts(jhosts)
> tcpping.setPortRange(0)
> tcpping.setValue("return_entire_cache", true)
> stack.addProtocol(tcpping)
> .addProtocol(new MERGE3)
> .addProtocol((new FD_SOCK)
> .setValue("bind_addr", localAddr)
> .setValue("client_bind_port", basePort + 1)
> .setValue("start_port", basePort + 101)
> .setValue("suspect_msg_interval", 1000))
> .addProtocol(new FD)
> .addProtocol((new VERIFY_SUSPECT)
> .setValue("timeout", 1000))
> .addProtocol((new NAKACK2)
> .setValue("use_mcast_xmit", false))
> .addProtocol(new UNICAST3)
> .addProtocol(new STABLE)
> .addProtocol(new MFC)
> .addProtocol(new SEQUENCER)
> .addProtocol((new GMS)
> .setValue("max_join_attempts", 3)
> .setValue("use_delta_views", false))
> .addProtocol(new FRAG2)
> {noformat}
--
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
12 years, 3 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 reopened JGRP-1827:
----------------------------
I'll take another look. Do you have a small sample program that shows the behavior ? I can't correlate your stack trace to the src as this is your port to Android to which I don't have the src code...
> 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
12 years, 3 months