August 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5265) Create EJB Timer quickstart - @Timeout and @Schedule.

by Ondrej Zizka (JIRA)

Ondrej Zizka created AS7-5265: --------------------------------- Summary: Create EJB Timer quickstart - @Timeout and @Schedule. Key: AS7-5265 URL: https://issues.jboss.org/browse/AS7-5265 Project: Application Server 7 Issue Type: Feature Request Reporter: Ondrej Zizka Assignee: Ondrej Zizka Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] (JBCLUSTER-33) Farm deploy of large EAR doesn't replicate to other cluster node

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-33?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-33: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > Farm deploy of large EAR doesn't replicate to other cluster node > ---------------------------------------------------------------- > > Key: JBCLUSTER-33 > URL: https://issues.jboss.org/browse/JBCLUSTER-33 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBoss AS 4.01SP1 + 4.0.1, Suse Linux > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Minor > Fix For: Q2Y5 > > Attachments: FarmMemberService.zip > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > I setup a two node JBoss cluster (either same machine or two different machines) and copy a large ear (22,725,139 byte file) into the farm deploy folder. The file doesn't replicate to the other server instance farm folder. I have seen an outOfMemory exception occur but increasing Java memory makes that go away, however, the EAR still doesn't replicate to the other node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-33) Farm deploy of large EAR doesn't replicate to other cluster node

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-33?page=com.atlassian.jira.plug... ] Scott Marlow closed JBCLUSTER-33. --------------------------------- > Farm deploy of large EAR doesn't replicate to other cluster node > ---------------------------------------------------------------- > > Key: JBCLUSTER-33 > URL: https://issues.jboss.org/browse/JBCLUSTER-33 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: JBoss AS 4.01SP1 + 4.0.1, Suse Linux > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Minor > Fix For: Q2Y5 > > Attachments: FarmMemberService.zip > > Time Spent: 4 hours > Remaining Estimate: 0 minutes > > I setup a two node JBoss cluster (either same machine or two different machines) and copy a large ear (22,725,139 byte file) into the farm deploy folder. The file doesn't replicate to the other server instance farm folder. I have seen an outOfMemory exception occur but increasing Java memory makes that go away, however, the EAR still doesn't replicate to the other node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-42) First deploy after joining a cluster is not farmed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-42?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-42: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > First deploy after joining a cluster is not farmed > -------------------------------------------------- > > Key: JBCLUSTER-42 > URL: https://issues.jboss.org/browse/JBCLUSTER-42 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Environment: Jboss 4.0.2 final, Java 1.5.0_02 > Reporter: Gabriele Garuglieri > Assignee: Scott Marlow > Fix For: Q2Y5 > > Time Spent: 3 hours > Remaining Estimate: 0 minutes > > There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup. > It happens with the following scenario. > 1- server starts up and joins the cluster, /farm applications are pulled from remote node. > 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names > 3- scanner thread is started and begins calling deploy() for each application > 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed > 5- you remove application from /farm and farmUndeploy() is invoked. > 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed > Then everything cleans up and for subsequent deploy/undeploy works correctly. > I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-42) First deploy after joining a cluster is not farmed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-42?page=com.atlassian.jira.plug... ] Scott Marlow closed JBCLUSTER-42. --------------------------------- > First deploy after joining a cluster is not farmed > -------------------------------------------------- > > Key: JBCLUSTER-42 > URL: https://issues.jboss.org/browse/JBCLUSTER-42 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: Q2Y5 > Environment: Jboss 4.0.2 final, Java 1.5.0_02 > Reporter: Gabriele Garuglieri > Assignee: Scott Marlow > Fix For: Q2Y5 > > Time Spent: 3 hours > Remaining Estimate: 0 minutes > > There a problem in org.jboss.ha.framework.server.FarmMemberService that shows during service startup. > It happens with the following scenario. > 1- server starts up and joins the cluster, /farm applications are pulled from remote node. > 2- farmDeploy() is called for the applications, remotelyDeployed gets filled with their names > 3- scanner thread is started and begins calling deploy() for each application > 4- by chance, deploy() executes while service status is still STARTING so it call super.deploy() and applications are deployed but their names are not removed from remotelyDeployed > 5- you remove application from /farm and farmUndeploy() is invoked. > 6- you put again application in /farm, deploy() is called, super.deploy() is called, BUT remotelyDeployed is still dirty from the preceding deploy so farmDeploy() is not invoked and the application won't get farmed > Then everything cleans up and for subsequent deploy/undeploy works correctly. > I tested the solution proposed by Scott Marlow Novell to move the clearing of "remotelyDeployed" flag before the "getState() == STARTING" test and it looks to be working. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-68) enhance farm deployment to handle cluster partitioning and merging

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-68?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-68: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > enhance farm deployment to handle cluster partitioning and merging > ------------------------------------------------------------------ > > Key: JBCLUSTER-68 > URL: https://issues.jboss.org/browse/JBCLUSTER-68 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Optional > > Handle partitions and merges. Here's a use case: > * Group is {A,B,C,D,E} > * Partition occurs > * Groups are now {A,B,C} and {D,E} > * User drops WAR into E > * D and E will have WAR > * Partition heals, merge occurs > o Group is now {A,B,C,D,E} > * A,B,C don't have the WAR, D and E have it > We could possibly use the same algorithm we use to reconcile this when D > and E were offline and a user dropped the WAR into E's ./farm dir. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-68) enhance farm deployment to handle cluster partitioning and merging

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-68?page=com.atlassian.jira.plug... ] Scott Marlow closed JBCLUSTER-68. --------------------------------- > enhance farm deployment to handle cluster partitioning and merging > ------------------------------------------------------------------ > > Key: JBCLUSTER-68 > URL: https://issues.jboss.org/browse/JBCLUSTER-68 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Scott Marlow (Novell) > Assignee: Scott Marlow > Priority: Optional > > Handle partitions and merges. Here's a use case: > * Group is {A,B,C,D,E} > * Partition occurs > * Groups are now {A,B,C} and {D,E} > * User drops WAR into E > * D and E will have WAR > * Partition heals, merge occurs > o Group is now {A,B,C,D,E} > * A,B,C don't have the WAR, D and E have it > We could possibly use the same algorithm we use to reconcile this when D > and E were offline and a user dropped the WAR into E's ./farm dir. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-44) Farm service startup performs way too many file transfers

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-44?page=com.atlassian.jira.plug... ] Scott Marlow reassigned JBCLUSTER-44: ------------------------------------- Assignee: Scott Marlow (was: Scott Marlow (Novell)) > Farm service startup performs way too many file transfers > --------------------------------------------------------- > > Key: JBCLUSTER-44 > URL: https://issues.jboss.org/browse/JBCLUSTER-44 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Jboss 4.0.2 final, Java 1.5.0_02 > Reporter: Gabriele Garuglieri > Assignee: Scott Marlow > Fix For: Q2Y5 > > Attachments: JBCLUSTER-44-2.txt, JBCLUSTER-44.txt > > > Suppose you have a cluster of N nodes and each node has A applications in the farm directory. > Now you join node (N+1) to cluster, it receives N farmDeployments responses and pullNewDeployments() is called for each response. > This means that each of the A applications is pulled from each of the N nodes for each call to pullNewDeployments(). > Now there are two problems, there are (N**2)*A transfers and for large values of N and A this may become a problem. It can be even worse if the size of A files is large and there may be a huge latency in startup. > Second, given that by definition the farming service keeps in sync all the member of the cluster, once the A files are pulled from the first cluster member then i have [(N**2)*A]-A useless transfers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBCLUSTER-44) Farm service startup performs way too many file transfers

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBCLUSTER-44?page=com.atlassian.jira.plug... ] Scott Marlow closed JBCLUSTER-44. --------------------------------- > Farm service startup performs way too many file transfers > --------------------------------------------------------- > > Key: JBCLUSTER-44 > URL: https://issues.jboss.org/browse/JBCLUSTER-44 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Environment: Jboss 4.0.2 final, Java 1.5.0_02 > Reporter: Gabriele Garuglieri > Assignee: Scott Marlow > Fix For: Q2Y5 > > Attachments: JBCLUSTER-44-2.txt, JBCLUSTER-44.txt > > > Suppose you have a cluster of N nodes and each node has A applications in the farm directory. > Now you join node (N+1) to cluster, it receives N farmDeployments responses and pullNewDeployments() is called for each response. > This means that each of the A applications is pulled from each of the N nodes for each call to pullNewDeployments(). > Now there are two problems, there are (N**2)*A transfers and for large values of N and A this may become a problem. It can be even worse if the size of A files is large and there may be a huge latency in startup. > Second, given that by definition the farming service keeps in sync all the member of the cluster, once the A files are pulled from the first cluster member then i have [(N**2)*A]-A useless transfers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-364) When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group

by Matthew Todd (JIRA)

When using TCP_NIO, starting two nodes at the same time causes one of the nodes not to join group ------------------------------------------------------------------------------------------------- Key: JGRP-364 URL: http://jira.jboss.com/jira/browse/JGRP-364 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Environment: linux 2.6 kernel x86_64 running java 1.5.0_06 Reporter: Matthew Todd Assigned To: Bela Ban I am testing a jgroups tcp_nio configuration using the draw demo.If I start up my 3 nodes one by one then everything works fine. However if I start up node 1, then attempt to start node 2 and 3 in parallel then only node 2 will work. Node 3 will be isolated and not see the other nodes and logs the following message: org.jgroups.protocols.pbcast.ClientGmsImpl join WARNING: join(192.158.70.200:7802) sent to 192.158.70.200:7800 timed out, retrying I am starting the draw demo like this; java -cp jgroups-all.jar:commons-logging.jar:concurrent.jar:jmxri.jar org.jgroups.demos.Draw -props test.xml Here is the configuration for one of my nodes: <config> <TCP_NIO bind_addr="192.158.70.200" recv_buf_size="20000000" send_buf_size="640000" loopback="false" discard_incompatible_packets="true" max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true" use_outgoing_packet_handler="true" down_thread="false" up_thread="false" enable_bundling="true" start_port="7800" end_port="7800" use_send_queues="false" sock_conn_timeout="300" skip_suspected_members="true" /> <MPING timeout="2000" num_initial_members="3" mcast_addr="229.6.7.8" bind_addr="192.158.70.200" down_thread="false" up_thread="false"/> <MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000"/> <FD_SOCK down_thread="false" up_thread="false"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" down_thread="true" up_thread="true" discard_delivered_msgs="true"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="true" up_thread="true" join_retry_timeout="2000" shun="true" view_bundling="true"/>  <pbcast.STATE_TRANSFER/>  </config> Node 2 and 3 have the same configuration except the port they bind to has been changed -- 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

13 years, 9 months

5
16
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2012