Search Results

Search found 204 results on 9 pages for 'teflon ted'.

Page 9/9 | < Previous Page | 5 6 7 8 9 

  • Troubleshooting latency spikes on ESXi NFS datastores

    - by exo_cw
    I'm experiencing fsync latencies of around five seconds on NFS datastores in ESXi, triggered by certain VMs. I suspect this might be caused by VMs using NCQ/TCQ, as this does not happen with virtual IDE drives. This can be reproduced using fsync-tester (by Ted Ts'o) and ioping. For example using a Grml live system with a 8GB disk: Linux 2.6.33-grml64: root@dynip211 /mnt/sda # ./fsync-tester fsync time: 5.0391 fsync time: 5.0438 fsync time: 5.0300 fsync time: 0.0231 fsync time: 0.0243 fsync time: 5.0382 fsync time: 5.0400 [... goes on like this ...] That is 5 seconds, not milliseconds. This is even creating IO-latencies on a different VM running on the same host and datastore: root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 . 4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms 4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms 4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms 4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms 4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms 4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms 4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms 4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms 4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms 4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms 4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms 4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms When I move the first VM to local storage it looks perfectly normal: root@dynip211 /mnt/sda # ./fsync-tester fsync time: 0.0191 fsync time: 0.0201 fsync time: 0.0203 fsync time: 0.0206 fsync time: 0.0192 fsync time: 0.0231 fsync time: 0.0201 [... tried that for one hour: no spike ...] Things I've tried that made no difference: Tested several ESXi Builds: 381591, 348481, 260247 Tested on different hardware, different Intel and AMD boxes Tested with different NFS servers, all show the same behavior: OpenIndiana b147 (ZFS sync always or disabled: no difference) OpenIndiana b148 (ZFS sync always or disabled: no difference) Linux 2.6.32 (sync or async: no difference) It makes no difference if the NFS server is on the same machine (as a virtual storage appliance) or on a different host Guest OS tested, showing problems: Windows 7 64 Bit (using CrystalDiskMark, latency spikes happen mostly during preparing phase) Linux 2.6.32 (fsync-tester + ioping) Linux 2.6.38 (fsync-tester + ioping) I could not reproduce this problem on Linux 2.6.18 VMs. Another workaround is to use virtual IDE disks (vs SCSI/SAS), but that is limiting performance and the number of drives per VM. Update 2011-06-30: The latency spikes seem to happen more often if the application writes in multiple small blocks before fsync. For example fsync-tester does this (strace output): pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576 fsync(3) = 0 ioping does this while preparing the file: [lots of pwrites] pwrite(3, "********************************"..., 4096, 1036288) = 4096 pwrite(3, "********************************"..., 4096, 1040384) = 4096 pwrite(3, "********************************"..., 4096, 1044480) = 4096 fsync(3) = 0 The setup phase of ioping almost always hangs, while fsync-tester sometimes works fine. Is someone capable of updating fsync-tester to write multiple small blocks? My C skills suck ;) Update 2011-07-02: This problem does not occur with iSCSI. I tried this with the OpenIndiana COMSTAR iSCSI server. But iSCSI does not give you easy access to the VMDK files so you can move them between hosts with snapshots and rsync. Update 2011-07-06: This is part of a wireshark capture, captured by a third VM on the same vSwitch. This all happens on the same host, no physical network involved. I've started ioping around time 20. There were no packets sent until the five second delay was over: No. Time Source Destination Protocol Info 1082 16.164096 192.168.250.10 192.168.250.20 NFS V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC 1083 16.164112 192.168.250.10 192.168.250.20 NFS V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC 1084 16.166060 192.168.250.20 192.168.250.10 TCP nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110 1085 16.167678 192.168.250.20 192.168.250.10 NFS V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC 1086 16.168280 192.168.250.20 192.168.250.10 NFS V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC 1087 16.168417 192.168.250.10 192.168.250.20 TCP iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016 1088 23.163028 192.168.250.10 192.168.250.20 NFS V3 GETATTR Call (Reply In 1089), FH:0x0bb04963 1089 23.164541 192.168.250.20 192.168.250.10 NFS V3 GETATTR Reply (Call In 1088) Directory mode:0777 uid:0 gid:0 1090 23.274252 192.168.250.10 192.168.250.20 TCP iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716 1091 24.924188 192.168.250.10 192.168.250.20 RPC Continuation 1092 24.924210 192.168.250.10 192.168.250.20 RPC Continuation 1093 24.924216 192.168.250.10 192.168.250.20 RPC Continuation 1094 24.924225 192.168.250.10 192.168.250.20 RPC Continuation 1095 24.924555 192.168.250.20 192.168.250.10 TCP nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986 1096 24.924626 192.168.250.10 192.168.250.20 RPC Continuation 1097 24.924635 192.168.250.10 192.168.250.20 RPC Continuation 1098 24.924643 192.168.250.10 192.168.250.20 RPC Continuation 1099 24.924649 192.168.250.10 192.168.250.20 RPC Continuation 1100 24.924653 192.168.250.10 192.168.250.20 RPC Continuation 2nd Update 2011-07-06: There seems to be some influence from TCP window sizes. I was not able to reproduce this problem using FreeNAS (based on FreeBSD) as a NFS server. The wireshark captures showed TCP window updates to 29127 bytes in regular intervals. I did not see them with OpenIndiana, which uses larger window sizes by default. I can no longer reproduce this problem if I set the following options in OpenIndiana and restart the NFS server: ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000 ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576 But this kills performance: Writing from /dev/zero to a file with dd_rescue goes from 170MB/s to 80MB/s. Update 2011-07-07: I've uploaded this tcpdump capture (can be analyzed with wireshark). In this case 192.168.250.2 is the NFS server (OpenIndiana b148) and 192.168.250.10 is the ESXi host. Things I've tested during this capture: Started "ioping -w 5 -i 0.2 ." at time 30, 5 second hang in setup, completed at time 40. Started "ioping -w 5 -i 0.2 ." at time 60, 5 second hang in setup, completed at time 70. Started "fsync-tester" at time 90, with the following output, stopped at time 120: fsync time: 0.0248 fsync time: 5.0197 fsync time: 5.0287 fsync time: 5.0242 fsync time: 5.0225 fsync time: 0.0209 2nd Update 2011-07-07: Tested another NFS server VM, this time NexentaStor 3.0.5 community edition: Shows the same problems. Update 2011-07-31: I can also reproduce this problem on the new ESXi build 4.1.0.433742.

    Read the article

  • Reverse engineering windows mobile live search CellID location awareness protocol (yikes)...

    - by Jean-Charles
    I wasn't sure of how to form the question so I apologize if the title is misleading. Additionally, you may want to get some coffee and take a seat for this one ... It's long. Basically, I'm trying to reverse engineer the protocol used by the Windows Mobile Live Search application to get location based on cellID. Before I go on, I am aware of other open source services (such as OpenCellID) but this is more for the sake of education and a bit for redundancy. According to the packets I captured, a POST request is made to ... mobile.search.live.com/positionlookupservice_1/service.aspx ... with a few specific headers (agent, content-length, etc) and no body. Once this goes through, the server sends back a 100-Continue response. At this point, the application submits this data (I chopped off the packet header): 00 00 00 01 00 00 00 05 55 54 ........UT 46 2d 38 05 65 6e 2d 55 53 05 65 6e 2d 55 53 01 F-8.en-US.en-US. 06 44 65 76 69 63 65 05 64 75 6d 6d 79 01 06 02 .Device.dummy... 50 4c 08 0e 52 65 76 65 72 73 65 47 65 6f 63 6f PL..ReverseGeoco 64 65 01 07 0b 47 50 53 43 68 69 70 49 6e 66 6f de...GPSChipInfo 01 20 06 09 43 65 6c 6c 54 6f 77 65 72 06 03 43 . ..CellTower..C 47 49 08 03 4d 43 43 b6 02 07 03 4d 4e 43 03 34 GI..MCC....MNC.4 31 30 08 03 4c 41 43 cf 36 08 02 43 49 fd 01 00 10..LAC.6..CI... 00 00 00 ... And receives this in response (packet and HTTP response headers chopped): 00 00 00 01 00 00 00 00 01 06 02 50 4c ...........PL 06 08 4c 6f 63 61 6c 69 74 79 06 08 4c 6f 63 61 ..Locality..Loca 74 69 6f 6e 07 03 4c 61 74 09 34 32 2e 33 37 35 tion..Lat.42.375 36 32 31 07 04 4c 6f 6e 67 0a 2d 37 31 2e 31 35 621..Long.-71.15 38 39 33 38 00 07 06 52 61 64 69 75 73 09 32 30 8938...Radius.20 30 30 2e 30 30 30 30 00 42 07 0c 4c 6f 63 61 6c 00.0000.B..Local 69 74 79 4e 61 6d 65 09 57 61 74 65 72 74 6f 77 ityName.Watertow 6e 07 16 41 64 6d 69 6e 69 73 74 72 61 74 69 76 n..Administrativ 65 41 72 65 61 4e 61 6d 65 0d 4d 61 73 73 61 63 eAreaName.Massac 68 75 73 65 74 74 73 07 10 50 6f 73 74 61 6c 43 husetts..PostalC 6f 64 65 4e 75 6d 62 65 72 05 30 32 34 37 32 07 odeNumber.02472. 0b 43 6f 75 6e 74 72 79 4e 61 6d 65 0d 55 6e 69 .CountryName.Uni 74 65 64 20 53 74 61 74 65 73 00 00 00 ted States... Now, here is what I've determined so far: All strings are prepended with one byte that is the decimal equivalent of their length. There seem to be three different casts that are used throughout the request and response. They show up as one byte before the length byte. I've concluded that the three types map out as follows: 0x06 - parent element (subsequent values are children, closed with 0x00) 0x07 - string 0x08 - int? Based on these determinations, here is what the request and response look like in a more readable manner (values surrounded by brackets denote length and values surrounded by parenthesis denote a cast): \0x00\0x00\0x00\0x01\0x00\0x00\0x00 [5]UTF-8 [5]en-US [5]en-US \0x01 [6]Device [5]dummy \0x01 (6)[2]PL (8)[14]ReverseGeocode\0x01 (7)[11]GPSChipInfo[1]\0x20 (6)[9]CellTower (6)[3]CGI (8)[3]MCC\0xB6\0x02 //310 (7)[3]MNC[3]410 //410 (8)[3]LAC\0xCF\0x36 //6991 (8)[2]CI\0xFD\0x01 //259 \0x00 \0x00 \0x00 \0x00 and.. \0x00\0x00\0x00\0x01\0x00\0x00\0x00 \0x00\0x01 (6)[2]PL (6)[8]Locality (6)[8]Location (7)[3]Lat[9]42.375621 (7)[4]Long[10]-71.158938 \0x00 (7)[6]Radius[9]2000.0000 \0x00 \0x42 //"B" ... Has to do with GSM (7)[12]LocalityName[9]Watertown (7)[22]AdministrativeAreaName[13]Massachusetts (7)[16]PostalCodeNumber[5]02472 (7)[11]CountryName[13]United States \0x00 \0x00\0x00 My analysis seems to work out pretty well except for a few things: The 0x01s throughout confuse me ... At first I thought they were some sort of base level element terminators but I'm not certain. I'm not sure the 7-byte header is, in fact, a seven byte header. I wonder if it's maybe 4 bytes and that the three remaining 0x00s are of some other significance. The trailing 0x00s. Why is it that there is only one on the request but two on the response? The type 8 cast mentioned above ... I can't seem to figure out how those values are being encoded. I added comments to those lines with what the values should correspond to. Any advice on these four points will be greatly appreciated. And yes, these packets were captured in Watertown, MA. :)

    Read the article

  • Scrum in 5 Minutes

    - by Stephen.Walther
    The goal of this blog entry is to explain the basic concepts of Scrum in less than five minutes. You learn how Scrum can help a team of developers to successfully complete a complex software project. Product Backlog and the Product Owner Imagine that you are part of a team which needs to create a new website – for example, an e-commerce website. You have an overwhelming amount of work to do. You need to build (or possibly buy) a shopping cart, install an SSL certificate, create a product catalog, create a Facebook page, and at least a hundred other things that you have not thought of yet. According to Scrum, the first thing you should do is create a list. Place the highest priority items at the top of the list and the lower priority items lower in the list. For example, creating the shopping cart and buying the domain name might be high priority items and creating a Facebook page might be a lower priority item. In Scrum, this list is called the Product Backlog. How do you prioritize the items in the Product Backlog? Different stakeholders in the project might have different priorities. Gary, your division VP, thinks that it is crucial that the e-commerce site has a mobile app. Sally, your direct manager, thinks taking advantage of new HTML5 features is much more important. Multiple people are pulling you in different directions. According to Scrum, it is important that you always designate one person, and only one person, as the Product Owner. The Product Owner is the person who decides what items should be added to the Product Backlog and the priority of the items in the Product Backlog. The Product Owner could be the customer who is paying the bills, the project manager who is responsible for delivering the project, or a customer representative. The critical point is that the Product Owner must always be a single person and that single person has absolute authority over the Product Backlog. Sprints and the Sprint Backlog So now the developer team has a prioritized list of items and they can start work. The team starts implementing the first item in the Backlog — the shopping cart — and the team is making good progress. Unfortunately, however, half-way through the work of implementing the shopping cart, the Product Owner changes his mind. The Product Owner decides that it is much more important to create the product catalog before the shopping cart. With some frustration, the team switches their developmental efforts to focus on implementing the product catalog. However, part way through completing this work, once again the Product Owner changes his mind about the highest priority item. Getting work done when priorities are constantly shifting is frustrating for the developer team and it results in lower productivity. At the same time, however, the Product Owner needs to have absolute authority over the priority of the items which need to get done. Scrum solves this conflict with the concept of Sprints. In Scrum, a developer team works in Sprints. At the beginning of a Sprint the developers and the Product Owner agree on the items from the backlog which they will complete during the Sprint. This subset of items from the Product Backlog becomes the Sprint Backlog. During the Sprint, the Product Owner is not allowed to change the items in the Sprint Backlog. In other words, the Product Owner cannot shift priorities on the developer team during the Sprint. Different teams use Sprints of different lengths such as one month Sprints, two-week Sprints, and one week Sprints. For high-stress, time critical projects, teams typically choose shorter sprints such as one week sprints. For more mature projects, longer one month sprints might be more appropriate. A team can pick whatever Sprint length makes sense for them just as long as the team is consistent. You should pick a Sprint length and stick with it. Daily Scrum During a Sprint, the developer team needs to have meetings to coordinate their work on completing the items in the Sprint Backlog. For example, the team needs to discuss who is working on what and whether any blocking issues have been discovered. Developers hate meetings (well, sane developers hate meetings). Meetings take developers away from their work of actually implementing stuff as opposed to talking about implementing stuff. However, a developer team which never has meetings and never coordinates their work also has problems. For example, Fred might get stuck on a programming problem for days and never reach out for help even though Tom (who sits in the cubicle next to him) has already solved the very same problem. Or, both Ted and Fred might have started working on the same item from the Sprint Backlog at the same time. In Scrum, these conflicting needs – limiting meetings but enabling team coordination – are resolved with the idea of the Daily Scrum. The Daily Scrum is a meeting for coordinating the work of the developer team which happens once a day. To keep the meeting short, each developer answers only the following three questions: 1. What have you done since yesterday? 2. What do you plan to do today? 3. Any impediments in your way? During the Daily Scrum, developers are not allowed to talk about issues with their cat, do demos of their latest work, or tell heroic stories of programming problems overcome. The meeting must be kept short — typically about 15 minutes. Issues which come up during the Daily Scrum should be discussed in separate meetings which do not involve the whole developer team. Stories and Tasks Items in the Product or Sprint Backlog – such as building a shopping cart or creating a Facebook page – are often referred to as User Stories or Stories. The Stories are created by the Product Owner and should represent some business need. Unlike the Product Owner, the developer team needs to think about how a Story should be implemented. At the beginning of a Sprint, the developer team takes the Stories from the Sprint Backlog and breaks the stories into tasks. For example, the developer team might take the Create a Shopping Cart story and break it into the following tasks: · Enable users to add and remote items from shopping cart · Persist the shopping cart to database between visits · Redirect user to checkout page when Checkout button is clicked During the Daily Scrum, members of the developer team volunteer to complete the tasks required to implement the next Story in the Sprint Backlog. When a developer talks about what he did yesterday or plans to do tomorrow then the developer should be referring to a task. Stories are owned by the Product Owner and a story is all about business value. In contrast, the tasks are owned by the developer team and a task is all about implementation details. A story might take several days or weeks to complete. A task is something which a developer can complete in less than a day. Some teams get lazy about breaking stories into tasks. Neglecting to break stories into tasks can lead to “Never Ending Stories” If you don’t break a story into tasks, then you can’t know how much of a story has actually been completed because you don’t have a clear idea about the implementation steps required to complete the story. Scrumboard During the Daily Scrum, the developer team uses a Scrumboard to coordinate their work. A Scrumboard contains a list of the stories for the current Sprint, the tasks associated with each Story, and the state of each task. The developer team uses the Scrumboard so everyone on the team can see, at a glance, what everyone is working on. As a developer works on a task, the task moves from state to state and the state of the task is updated on the Scrumboard. Common task states are ToDo, In Progress, and Done. Some teams include additional task states such as Needs Review or Needs Testing. Some teams use a physical Scrumboard. In that case, you use index cards to represent the stories and the tasks and you tack the index cards onto a physical board. Using a physical Scrumboard has several disadvantages. A physical Scrumboard does not work well with a distributed team – for example, it is hard to share the same physical Scrumboard between Boston and Seattle. Also, generating reports from a physical Scrumboard is more difficult than generating reports from an online Scrumboard. Estimating Stories and Tasks Stakeholders in a project, the people investing in a project, need to have an idea of how a project is progressing and when the project will be completed. For example, if you are investing in creating an e-commerce site, you need to know when the site can be launched. It is not enough to just say that “the project will be done when it is done” because the stakeholders almost certainly have a limited budget to devote to the project. The people investing in the project cannot determine the business value of the project unless they can have an estimate of how long it will take to complete the project. Developers hate to give estimates. The reason that developers hate to give estimates is that the estimates are almost always completely made up. For example, you really don’t know how long it takes to build a shopping cart until you finish building a shopping cart, and at that point, the estimate is no longer useful. The problem is that writing code is much more like Finding a Cure for Cancer than Building a Brick Wall. Building a brick wall is very straightforward. After you learn how to add one brick to a wall, you understand everything that is involved in adding a brick to a wall. There is no additional research required and no surprises. If, on the other hand, I assembled a team of scientists and asked them to find a cure for cancer, and estimate exactly how long it will take, they would have no idea. The problem is that there are too many unknowns. I don’t know how to cure cancer, I need to do a lot of research here, so I cannot even begin to estimate how long it will take. So developers hate to provide estimates, but the Product Owner and other product stakeholders, have a legitimate need for estimates. Scrum resolves this conflict by using the idea of Story Points. Different teams use different units to represent Story Points. For example, some teams use shirt sizes such as Small, Medium, Large, and X-Large. Some teams prefer to use Coffee Cup sizes such as Tall, Short, and Grande. Finally, some teams like to use numbers from the Fibonacci series. These alternative units are converted into a Story Point value. Regardless of the type of unit which you use to represent Story Points, the goal is the same. Instead of attempting to estimate a Story in hours (which is doomed to failure), you use a much less fine-grained measure of work. A developer team is much more likely to be able to estimate that a Story is Small or X-Large than the exact number of hours required to complete the story. So you can think of Story Points as a compromise between the needs of the Product Owner and the developer team. When a Sprint starts, the developer team devotes more time to thinking about the Stories in a Sprint and the developer team breaks the Stories into Tasks. In Scrum, you estimate the work required to complete a Story by using Story Points and you estimate the work required to complete a task by using hours. The difference between Stories and Tasks is that you don’t create a task until you are just about ready to start working on a task. A task is something that you should be able to create within a day, so you have a much better chance of providing an accurate estimate of the work required to complete a task than a story. Burndown Charts In Scrum, you use Burndown charts to represent the remaining work on a project. You use Release Burndown charts to represent the overall remaining work for a project and you use Sprint Burndown charts to represent the overall remaining work for a particular Sprint. You create a Release Burndown chart by calculating the remaining number of uncompleted Story Points for the entire Product Backlog every day. The vertical axis represents Story Points and the horizontal axis represents time. A Sprint Burndown chart is similar to a Release Burndown chart, but it focuses on the remaining work for a particular Sprint. There are two different types of Sprint Burndown charts. You can either represent the remaining work in a Sprint with Story Points or with task hours (the following image, taken from Wikipedia, uses hours). When each Product Backlog Story is completed, the Release Burndown chart slopes down. When each Story or task is completed, the Sprint Burndown chart slopes down. Burndown charts typically do not always slope down over time. As new work is added to the Product Backlog, the Release Burndown chart slopes up. If new tasks are discovered during a Sprint, the Sprint Burndown chart will also slope up. The purpose of a Burndown chart is to give you a way to track team progress over time. If, halfway through a Sprint, the Sprint Burndown chart is still climbing a hill then you know that you are in trouble. Team Velocity Stakeholders in a project always want more work done faster. For example, the Product Owner for the e-commerce site wants the website to launch before tomorrow. Developers tend to be overly optimistic. Rarely do developers acknowledge the physical limitations of reality. So Project stakeholders and the developer team often collude to delude themselves about how much work can be done and how quickly. Too many software projects begin in a state of optimism and end in frustration as deadlines zoom by. In Scrum, this problem is overcome by calculating a number called the Team Velocity. The Team Velocity is a measure of the average number of Story Points which a team has completed in previous Sprints. Knowing the Team Velocity is important during the Sprint Planning meeting when the Product Owner and the developer team work together to determine the number of stories which can be completed in the next Sprint. If you know the Team Velocity then you can avoid committing to do more work than the team has been able to accomplish in the past, and your team is much more likely to complete all of the work required for the next Sprint. Scrum Master There are three roles in Scrum: the Product Owner, the developer team, and the Scrum Master. I’v e already discussed the Product Owner. The Product Owner is the one and only person who maintains the Product Backlog and prioritizes the stories. I’ve also described the role of the developer team. The members of the developer team do the work of implementing the stories by breaking the stories into tasks. The final role, which I have not discussed, is the role of the Scrum Master. The Scrum Master is responsible for ensuring that the team is following the Scrum process. For example, the Scrum Master is responsible for making sure that there is a Daily Scrum meeting and that everyone answers the standard three questions. The Scrum Master is also responsible for removing (non-technical) impediments which the team might encounter. For example, if the team cannot start work until everyone installs the latest version of Microsoft Visual Studio then the Scrum Master has the responsibility of working with management to get the latest version of Visual Studio as quickly as possible. The Scrum Master can be a member of the developer team. Furthermore, different people can take on the role of the Scrum Master over time. The Scrum Master, however, cannot be the same person as the Product Owner. Using SonicAgile SonicAgile (SonicAgile.com) is an online tool which you can use to manage your projects using Scrum. You can use the SonicAgile Product Backlog to create a prioritized list of stories. You can estimate the size of the Stories using different Story Point units such as Shirt Sizes and Coffee Cup sizes. You can use SonicAgile during the Sprint Planning meeting to select the Stories that you want to complete during a particular Sprint. You can configure Sprints to be any length of time. SonicAgile calculates Team Velocity automatically and displays a warning when you add too many stories to a Sprint. In other words, it warns you when it thinks you are overcommitting in a Sprint. SonicAgile also includes a Scrumboard which displays the list of Stories selected for a Sprint and the tasks associated with each story. You can drag tasks from one task state to another. Finally, SonicAgile enables you to generate Release Burndown and Sprint Burndown charts. You can use these charts to view the progress of your team. To learn more about SonicAgile, visit SonicAgile.com. Summary In this post, I described many of the basic concepts of Scrum. You learned how a Product Owner uses a Product Backlog to create a prioritized list of tasks. I explained why work is completed in Sprints so the developer team can be more productive. I also explained how a developer team uses the daily scrum to coordinate their work. You learned how the developer team uses a Scrumboard to see, at a glance, who is working on what and the state of each task. I also discussed Burndown charts. You learned how you can use both Release and Sprint Burndown charts to track team progress in completing a project. Finally, I described the crucial role of the Scrum Master – the person who is responsible for ensuring that the rules of Scrum are being followed. My goal was not to describe all of the concepts of Scrum. This post was intended to be an introductory overview. For a comprehensive explanation of Scrum, I recommend reading Ken Schwaber’s book Agile Project Management with Scrum: http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X/ref=la_B001H6ODMC_1_1?ie=UTF8&qid=1345224000&sr=1-1

    Read the article

  • JBoss AS 5: starts but can't connect (Windows, remote)

    - by Nuwan
    Hello I installed Jboss 5.0GA and Its works fine in localhost.But I want It to access through remote Machine.Then I bind my IP address to my server and started it.This is the command I used run.bat -b 10.17.62.63 Then the server Starts fine This is the console log when starting the server > =============================================================================== > > JBoss Bootstrap Environment > > JBOSS_HOME: C:\jboss-5.0.0.GA > > JAVA: C:\Program Files\Java\jdk1.6.0_34\bin\java > > JAVA_OPTS: -Dprogram.name=run.bat -server -Xms128m -Xmx512m > -XX:MaxPermSize=25 6m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Ds un.rmi.dgc.server.gcInterval=3600000 > > CLASSPATH: C:\jboss-5.0.0.GA\bin\run.jar > > =============================================================================== > > run.bat: unused non-option argument: ûb run.bat: unused non-option > argument: 0.0.0.0 13:43:38,179 INFO [ServerImpl] Starting JBoss > (Microcontainer)... 13:43:38,179 INFO [ServerImpl] Release ID: JBoss > [Morpheus] 5.0.0.GA (build: SV NTag=JBoss_5_0_0_GA date=200812041714) > 13:43:38,179 INFO [ServerImpl] Bootstrap URL: null 13:43:38,179 INFO > [ServerImpl] Home Dir: C:\jboss-5.0.0.GA 13:43:38,179 INFO > [ServerImpl] Home URL: file:/C:/jboss-5.0.0.GA/ 13:43:38,195 INFO > [ServerImpl] Library URL: file:/C:/jboss-5.0.0.GA/lib/ 13:43:38,195 > INFO [ServerImpl] Patch URL: null 13:43:38,195 INFO [ServerImpl] > Common Base URL: file:/C:/jboss-5.0.0.GA/common/ > > 13:43:38,195 INFO [ServerImpl] Common Library URL: > file:/C:/jboss-5.0.0.GA/comm on/lib/ 13:43:38,195 INFO [ServerImpl] > Server Name: default 13:43:38,195 INFO [ServerImpl] Server Base Dir: > C:\jboss-5.0.0.GA\server 13:43:38,195 INFO [ServerImpl] Server Base > URL: file:/C:/jboss-5.0.0.GA/server/ > > 13:43:38,210 INFO [ServerImpl] Server Config URL: > file:/C:/jboss-5.0.0.GA/serve r/default/conf/ 13:43:38,210 INFO > [ServerImpl] Server Home Dir: C:\jboss-5.0.0.GA\server\defaul t > 13:43:38,210 INFO [ServerImpl] Server Home URL: > file:/C:/jboss-5.0.0.GA/server/ default/ 13:43:38,210 INFO > [ServerImpl] Server Data Dir: C:\jboss-5.0.0.GA\server\defaul t\data > 13:43:38,210 INFO [ServerImpl] Server Library URL: > file:/C:/jboss-5.0.0.GA/serv er/default/lib/ 13:43:38,210 INFO > [ServerImpl] Server Log Dir: C:\jboss-5.0.0.GA\server\default \log > 13:43:38,210 INFO [ServerImpl] Server Native Dir: > C:\jboss-5.0.0.GA\server\defa ult\tmp\native 13:43:38,210 INFO > [ServerImpl] Server Temp Dir: C:\jboss-5.0.0.GA\server\defaul t\tmp > 13:43:38,210 INFO [ServerImpl] Server Temp Deploy Dir: > C:\jboss-5.0.0.GA\server \default\tmp\deploy 13:43:39,710 INFO > [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/j > boss-5.0.0.GA/server/default/conf/bootstrap.xml 13:43:40,851 INFO > [VFSCacheFactory] Initializing VFSCache [org.jboss.virtual.pl > ugins.cache.IterableTimedVFSCache] 13:43:40,866 INFO > [VFSCacheFactory] Using VFSCache [IterableTimedVFSCache{lifet > ime=1800, resolution=60}] 13:43:41,616 INFO [CopyMechanism] VFS temp > dir: C:\jboss-5.0.0.GA\server\defaul t\tmp 13:43:41,648 INFO > [ZipEntryContext] VFS force nested jars copy-mode is enabled. > > 13:43:44,288 INFO [ServerInfo] Java version: 1.6.0_34,Sun > Microsystems Inc. 13:43:44,288 INFO [ServerInfo] Java VM: Java > HotSpot(TM) Server VM 20.9-b04,Sun Microsystems Inc. 13:43:44,288 > INFO [ServerInfo] OS-System: Windows XP 5.1,x86 13:43:44,569 INFO > [JMXKernel] Legacy JMX core initialized 13:43:50,148 INFO > [ProfileServiceImpl] Loading profile: default from: org.jboss > .system.server.profileservice.repository.SerializableDeploymentRepository@e72f0c > (root=C:\jboss-5.0.0.GA\server, > key=org.jboss.profileservice.spi.ProfileKey@143b > 82c3[domain=default,server=default,name=default]) 13:43:50,148 INFO > [ProfileImpl] Using repository:org.jboss.system.server.profil > eservice.repository.SerializableDeploymentRepository@e72f0c(root=C:\jboss-5.0.0. > GA\server, > key=org.jboss.profileservice.spi.ProfileKey@143b82c3[domain=default,s > erver=default,name=default]) 13:43:50,148 INFO [ProfileServiceImpl] > Loaded profile: ProfileImpl@8b3bb3{key=o > rg.jboss.profileservice.spi.ProfileKey@143b82c3[domain=default,server=default,na > me=default]} 13:43:54,804 INFO [WebService] Using RMI server > codebase: http://127.0.0.1:8083 / 13:44:12,147 INFO [CXFServerConfig] > JBoss Web Services - Stack CXF Runtime Serv er 13:44:12,147 INFO > [CXFServerConfig] 3.1.2.GA 13:44:29,788 INFO > [Ejb3DependenciesDeployer] Encountered deployment AbstractVFS > DeploymentContext@29776073{vfszip:/C:/jboss-5.0.0.GA/server/default/deploy/myE-e > jb.jar} 13:44:29,819 INFO [Ejb3DependenciesDeployer] Encountered > deployment AbstractVFS > DeploymentContext@29776073{vfszip:/C:/jboss-5.0.0.GA/server/default/deploy/myE-e > jb.jar} 13:44:29,819 INFO [Ejb3DependenciesDeployer] Encountered > deployment AbstractVFS > DeploymentContext@29776073{vfszip:/C:/jboss-5.0.0.GA/server/default/deploy/myE-e > jb.jar} 13:44:29,819 INFO [Ejb3DependenciesDeployer] Encountered > deployment AbstractVFS > DeploymentContext@29776073{vfszip:/C:/jboss-5.0.0.GA/server/default/deploy/myE-e > jb.jar} 13:44:37,116 INFO [JMXConnectorServerService] JMX Connector > server: service:jmx > :rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector 13:44:38,022 > INFO [MailService] Mail Service bound to java:/Mail 13:44:43,162 WARN > [JBossASSecurityMetadataStore] WARNING! POTENTIAL SECURITY RI SK. It > has been detected that the MessageSucker component which sucks > messages f rom one node to another has not had its password changed > from the installation d efault. Please see the JBoss Messaging user > guide for instructions on how to do this. 13:44:43,209 WARN > [AnnotationCreator] No ClassLoader provided, using TCCL: org. > jboss.managed.api.annotation.ManagementComponent 13:44:43,600 INFO > [TransactionManagerService] JBossTS Transaction Service (JTA version) > - JBoss Inc. 13:44:43,600 INFO [TransactionManagerService] Setting up property manager MBean and JMX layer 13:44:44,366 INFO > [TransactionManagerService] Initializing recovery manager 13:44:44,678 > INFO [TransactionManagerService] Recovery manager configured > 13:44:44,678 INFO [TransactionManagerService] Binding > TransactionManager JNDI R eference 13:44:44,787 INFO > [TransactionManagerService] Starting transaction recovery man ager > 13:44:46,428 INFO [Http11Protocol] Initializing Coyote HTTP/1.1 on > http-127.0.0 .1-8080 13:44:46,459 INFO [AjpProtocol] Initializing > Coyote AJP/1.3 on ajp-127.0.0.1-80 09 13:44:46,459 INFO > [StandardService] Starting service jboss.web 13:44:46,475 INFO > [StandardEngine] Starting Servlet Engine: JBoss Web/2.1.1.GA > 13:44:46,616 INFO [Catalina] Server startup in 350 ms 13:44:46,709 > INFO [TomcatDeployment] deploy, ctxPath=/web-console, vfsUrl=manag > ement/console-mgr.sar/web-console.war 13:44:48,553 INFO > [TomcatDeployment] deploy, ctxPath=/juddi, vfsUrl=juddi-servi > ce.sar/juddi.war 13:44:48,678 INFO [RegistryServlet] Loading jUDDI > configuration. 13:44:48,694 INFO [RegistryServlet] Resources loaded > from: /WEB-INF/juddi.prope rties 13:44:48,709 INFO [RegistryServlet] > Initializing jUDDI components. 13:44:48,991 INFO [TomcatDeployment] > deploy, ctxPath=/invoker, vfsUrl=http-invo ker.sar/invoker.war > 13:44:49,162 INFO [TomcatDeployment] deploy, ctxPath=/jbossws, > vfsUrl=jbossws.s ar/jbossws-management.war 13:44:49,475 INFO > [RARDeployment] Required license terms exist, view vfszip:/C: > /jboss-5.0.0.GA/server/default/deploy/jboss-local-jdbc.rar/META-INF/ra.xml > 13:44:49,569 INFO [RARDeployment] Required license terms exist, view > vfszip:/C: > /jboss-5.0.0.GA/server/default/deploy/jboss-xa-jdbc.rar/META-INF/ra.xml > 13:44:49,741 INFO [RARDeployment] Required license terms exist, view > vfszip:/C: > /jboss-5.0.0.GA/server/default/deploy/jms-ra.rar/META-INF/ra.xml > 13:44:49,819 INFO [RARDeployment] Required license terms exist, view > vfszip:/C: > /jboss-5.0.0.GA/server/default/deploy/mail-ra.rar/META-INF/ra.xml > 13:44:49,912 INFO [RARDeployment] Required license terms exist, view > vfszip:/C: > /jboss-5.0.0.GA/server/default/deploy/quartz-ra.rar/META-INF/ra.xml > 13:44:50,069 INFO [SimpleThreadPool] Job execution threads will use > class loade r of thread: main 13:44:50,115 INFO [QuartzScheduler] > Quartz Scheduler v.1.5.2 created. 13:44:50,131 INFO [RAMJobStore] > RAMJobStore initialized. 13:44:50,131 INFO [StdSchedulerFactory] > Quartz scheduler 'DefaultQuartzSchedule r' initialized from default > resource file in Quartz package: 'quartz.properties' > > 13:44:50,131 INFO [StdSchedulerFactory] Quartz scheduler version: > 1.5.2 13:44:50,131 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUS TERED started. 13:44:51,194 INFO > [ConnectionFactoryBindingService] Bound ConnectionManager 'jb > oss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name > 'java:DefaultDS' 13:44:51,819 WARN [QuartzTimerServiceFactory] sql > failed: CREATE TABLE QRTZ_JOB > _DETAILS(JOB_NAME VARCHAR(80) NOT NULL, JOB_GROUP VARCHAR(80) NOT NULL, DESCRIPT ION VARCHAR(120) NULL, JOB_CLASS_NAME VARCHAR(128) NOT > NULL, IS_DURABLE VARCHAR( 1) NOT NULL, IS_VOLATILE VARCHAR(1) NOT > NULL, IS_STATEFUL VARCHAR(1) NOT NULL, R EQUESTS_RECOVERY VARCHAR(1) > NOT NULL, JOB_DATA BINARY NULL, PRIMARY KEY (JOB_NAM E,JOB_GROUP)) > 13:44:51,912 INFO [SimpleThreadPool] Job execution threads will use > class loade r of thread: main 13:44:51,928 INFO [QuartzScheduler] > Quartz Scheduler v.1.5.2 created. 13:44:51,928 INFO [JobStoreCMT] > Using db table-based data access locking (synch ronization). > 13:44:51,944 INFO [JobStoreCMT] Removed 0 Volatile Trigger(s). > 13:44:51,944 INFO [JobStoreCMT] Removed 0 Volatile Job(s). > 13:44:51,944 INFO [JobStoreCMT] JobStoreCMT initialized. 13:44:51,944 > INFO [StdSchedulerFactory] Quartz scheduler 'JBossEJB3QuartzSchedu > ler' initialized from an externally provided properties instance. > 13:44:51,959 INFO [StdSchedulerFactory] Quartz scheduler version: > 1.5.2 13:44:51,959 INFO [JobStoreCMT] Freed 0 triggers from 'acquired' / 'blocked' st ate. 13:44:51,975 INFO [JobStoreCMT] > Recovering 0 jobs that were in-progress at the time of the last > shut-down. 13:44:51,975 INFO [JobStoreCMT] Recovery complete. > 13:44:51,975 INFO [JobStoreCMT] Removed 0 'complete' triggers. > 13:44:51,975 INFO [JobStoreCMT] Removed 0 stale fired job entries. > 13:44:51,990 INFO [QuartzScheduler] Scheduler > JBossEJB3QuartzScheduler_$_NON_CL USTERED started. 13:44:52,381 INFO > [ServerPeer] JBoss Messaging 1.4.1.GA server [0] started 13:44:52,569 > INFO [QueueService] Queue[/queue/DLQ] started, fullSize=200000, pa > geSize=2000, downCacheSize=2000 13:44:52,584 INFO [QueueService] > Queue[/queue/ExpiryQueue] started, fullSize=20 0000, pageSize=2000, > downCacheSize=2000 13:44:52,709 INFO [ConnectionFactory] Connector > bisocket://127.0.0.1:4457 has l easing enabled, lease period 10000 > milliseconds 13:44:52,709 INFO [ConnectionFactory] > org.jboss.jms.server.connectionfactory.Co nnectionFactory@1a8ac5e > started 13:44:52,725 WARN [ConnectionFactoryJNDIMapper] > supportsFailover attribute is t rue on connection factory: > jboss.messaging.connectionfactory:service=ClusteredCo nnectionFactory > but post office is non clustered. So connection factory will *no t* > support failover 13:44:52,725 WARN [ConnectionFactoryJNDIMapper] > supportsLoadBalancing attribute is true on connection factory: > jboss.messaging.connectionfactory:service=Cluste redConnectionFactory > but post office is non clustered. So connection factory wil l *not* > support load balancing 13:44:52,740 INFO [ConnectionFactory] > Connector bisocket://127.0.0.1:4457 has l easing enabled, lease period > 10000 milliseconds 13:44:52,740 INFO [ConnectionFactory] > org.jboss.jms.server.connectionfactory.Co nnectionFactory@1d43178 > started 13:44:52,740 INFO [ConnectionFactory] Connector > bisocket://127.0.0.1:4457 has l easing enabled, lease period 10000 > milliseconds 13:44:52,756 INFO [ConnectionFactory] > org.jboss.jms.server.connectionfactory.Co nnectionFactory@52728a > started 13:44:53,084 INFO [ConnectionFactoryBindingService] Bound > ConnectionManager 'jb > oss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name > 'java:JmsXA' 13:44:53,225 INFO [TomcatDeployment] deploy, ctxPath=/, > vfsUrl=ROOT.war 13:44:53,553 INFO [TomcatDeployment] deploy, > ctxPath=/jmx-console, vfsUrl=jmx-c onsole.war 13:44:53,975 INFO > [TomcatDeployment] deploy, ctxPath=/TestService, vfsUrl=TestS > erviceEAR.ear/TestService.war 13:44:55,662 INFO [JBossASKernel] > Created KernelDeployment for: myE-ejb.jar 13:44:55,709 INFO > [JBossASKernel] installing bean: jboss.j2ee:jar=myE-ejb.jar,n > ame=RPSService,service=EJB3 13:44:55,725 INFO [JBossASKernel] with > dependencies: 13:44:55,725 INFO [JBossASKernel] and demands: > 13:44:55,725 INFO [JBossASKernel] > jboss.ejb:service=EJBTimerService 13:44:55,725 INFO [JBossASKernel] > and supplies: 13:44:55,725 INFO [JBossASKernel] > jndi:RPSService/remote 13:44:55,725 INFO [JBossASKernel] Added > bean(jboss.j2ee:jar=myE-ejb.jar,name=RP SService,service=EJB3) to > KernelDeployment of: myE-ejb.jar 13:44:56,772 INFO > [SessionSpecContainer] Starting jboss.j2ee:jar=myE-ejb.jar,na > me=RPSService,service=EJB3 13:44:56,803 INFO [EJBContainer] STARTED > EJB: com.monz.rpz.RPSService ejbName: RPSService 13:44:56,819 INFO > [JndiSessionRegistrarBase] Binding the following Entries in G lobal > JNDI: > > > 13:44:57,381 INFO [DefaultEndpointRegistry] register: > jboss.ws:context=myE-ejb, endpoint=RPSService 13:44:57,428 INFO > [DescriptorDeploymentAspect] Add Service id=RPSService > address=http://127.0.0.1:8080/myE-ejb/RPSService > implementor=com.monz.rpz.RPSService > invoker=org.jboss.wsf.stack.cxf.InvokerEJB3 mtomEnabled=false > 13:44:57,459 INFO [DescriptorDeploymentAspect] JBossWS-CXF > configuration genera ted: > file:/C:/jboss-5.0.0.GA/server/default/tmp/jbossws/jbossws-cxf1864137209199 > 110130.xml 13:44:57,569 INFO [TomcatDeployment] deploy, ctxPath=/myE-ejb, vfsUrl=myE-ejb.j ar 13:44:57,709 WARN [config] > Unable to process deployment descriptor for context '/myE-ejb' > 13:44:59,334 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on > http-127.0.0.1-8 080 13:44:59,397 INFO [AjpProtocol] Starting Coyote > AJP/1.3 on ajp-127.0.0.1-8009 13:44:59,459 INFO [ServerImpl] JBoss > (Microcontainer) [5.0.0.GA (build: SVNTag= JBoss_5_0_0_GA > date=200812041714)] Started in 1m:21s:233ms But Still I cant connect to It when I Type my IP address in my browser thanks

    Read the article

< Previous Page | 5 6 7 8 9